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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



MBMS is a point- to -multipoint service in which data is transmitted from a single source entity to multiple recipients. 
Transmitting the same data to multiple recipients allows network resources to be shared. 

The MBMS bearer service offers two modes: 

• Broadcast Mode. 

• Multicast Mode. 

MBMS user services can be built on top of the MBMS bearer service. Further, the MBMS User Services may use other 
UMTS bearer services to deliver data. The present document specifies two delivery methods for the MBMS user 
services: download and streaming. Examples of applications using the download delivery method are news and 
software upgrades. Delivery of live music is an example of an application using the streaming delivery method. 

There can be several MBMS user services. The objective of the present document is the definition of a set of media 
codecs, formats and transport/application protocols to enable the deployment of MBMS user services. The present 
document takes into consideration the need to maximize the reuse of components of already specified services like PSS 
and MMS. 
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Scope 



The present document defines a set of media codecs, formats and transport/application protocols to enable the 
deployment of MBMS user services either over the MBMS bearer service or other UMTS Bearer Services within the 
3GPP system. 

In this version of the specification, only MBMS download and streaming delivery methods are specified. The present 
document does not preclude the use of other delivery methods. 

The present document includes information applicable to network operators, service providers and manufacturers. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [1] and the following 
apply: 

Broadcast session: See 3GPP TS 22.146 [2]. 

Forward Error Correction (FEC): in the context of MBMS, a FEC mechanism is used at the application layer to 
allow MBMS receivers to recover lost SDUs 

FLUTE channel: equivalent to an ALC/LCT channel 

An ALC/LCT channel is defined by the combination of a sender and an address associated with the channel by the 

sender (RFC 3926 [9]). 

Multicast joining: See 3GPP TS 22.146 [2]. 

Multicast session: See 3GPP TS 22.146 [2]. 

Multimedia Broadcast/Multicast Service (MBMS): See 3GPP TS 22.146 [2]. 

MBMS over a Single Frequency Network: See 3GPP TS 25.346 [5] 

MBMS user services: MBMS User Service may use more than one Multimedia Broadcast/Multicast Service (bearer 
service) and more than one Broadcast and/or Multicast session 

See 3GPPTS 22.246 [3]. 

MBMS user service discovery/announcement: user service discovery refers to methods for the UE to obtain the list of 
available MBMS user services along with information on the user service and the user service announcement refers to 
methods for the MBMS service provider to make the list of available MBMS user services along with information on 
the user service available to the UE 

MBMS user service initiation: UE mechanisms to setup the reception of MBMS user service data 
The initiation procedure takes place after the discovery of the MBMS user service 

MBMS delivery method: mechanism used by a MBMS user service to deliver content 

An MBMS delivery method uses MBMS bearers in delivering content and may make use of associated procedures. 

MBMS download delivery method: delivery of discrete objects (e.g. files) by means of a MBMS download session 

MBMS streaming delivery method: delivery of continuous media (e.g. real-time video) by means of a MBMS 
streaming session 

MBMS download session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the download of content files 

MBMS streaming session: time, protocols and protocol state (i.e. parameters) which define sender and receiver 
configuration for the streaming of content 
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RTP Session: The RTP and RTCP traffic sent to a specific IP multicast address and port pair (one port each for RTP 
and RTCP) during the time period the session is specified to exist. An RTP session is used to transport a single media 
type (e.g. audio, video, or text). An RTP session may contain several different streams of RTP packets using different 
SSRCs. 

Unicast Bearer Service: Synonymously used as the term "UMTS Bearer Services with interactive and/or streaming 
traffic classes". 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

ALC Asynchronous Layered Coding 

APN Access Point Name 

AVC Advanced Video Coding 

BM-SC Broadcast-Multicast - Service Centre 

CC Congestion Control 

DIMS Dynamic and Interactive Multimedia Scenes 

ERT Expected Residual Time 

ESI Encoding Symbol ID 

FDT File Delivery Table 

EEC Forward Error Correction 

FLUTE File deLivery over Unidirectional Transport 

FMT Feedback Message Type 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

lANA Internet Assigned Numbers Authority 

IP Internet Protocol 

LCT Layered Coding Transport 

MBMS Multimedia Broadcast/Multicast Service 

MBSFN MBMS over a Single Frequency Network 

MIME Multipurpose Internet Mail Extensions 

MMS Multimedia Messaging Service 

MS Mobile Station 

MSK MBMS Service Key 

MTK MBMS Traffic Key 

MUK MBMS User Key 

NTP Network Time Protocol 

PDP Packet Data Protocol 

PSS Packet-switched Streaming Service 

PTM Point To Multipoint 

PTP Point To Point 

RTP Real-time Transport Protocol 

SBN Source Block Number 

SCT Sender Current Time 

SDP Session Description Protocol 

SDU Service Data Unit 

SEI Supplemental Enhancement Information 

SGSN Serving GPRS Support Node 

SNTP Simple Network Time Protocol 

TMGI Temporary Mobile Group Identity 

TOI Transport Object Identifier 

TSI Transport Session Identifier 

UDP User Datagram Protocol 

UE User Equipment 

UML Unified Modelling Language 

URI Uniform Resource Identifier 

URL Uniform Resource Locator 

USD User Service Description 

UTC Universal Time Coordinated 

XML extensible Markup Language 
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4 MBMS system description 

4.1 IVIBMS functional layers 

Three distinct functional layers are defined for the delivery of MBMS-based service. They are Bearers, Delivery 
method and User service. Figure 1 depicts these layers with examples of bearer types, delivery methods and 
applications. 
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Bearers: Bearers provide the mechanism by which IP data is transported. IVIBIVIS bearers as defined in 

3GPP TS 23.246 [4] and 3GPP TS 22.146 [3] are used to transport multicast and broadcast traffic 
in an efficient one-to-many manner and are the foundation of IVIBMS-based services. MBMS 
bearers may be used jointly with unicast PDP contexts in offering complete service capabilities. 

Delivery Method: When delivering MBMS content to a receiving application one or more delivery methods are used. 
The delivery layer provides functionality such as security and key distribution, reliability control by 
means of forward-error-correction techniques and associated delivery procedures such as file- 
repair, delivery verification. Two delivery methods are defined, namely download and streaming. 
Delivery methods may be added beyond the current release. Delivery methods may use MBMS 
bearers and may make use of point-to-point bearers through a set of MBMS associated 
procedures. 

User service: The MBMS User service enables applications. Different applications impose different 

requirements when delivering content to MBMS subscribers and may use different MBMS delivery 
methods. As an example a messaging application such as MMS would use the download delivery 
method while a streaming application such as PSS would use the streaming delivery method. 

Figure 1 : Functional Layers for MBMS User Service 

4.2 IVIBIVIS User Service Entities 

Figure 2 shows the MBMS user service entities and their inter-relations. Relation cardinality is depicted as well. 
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Figure 2: Entities and Relations 

An MBMS user service is an entity that is used in presenting a complete service offering to the end-user and allowing 
him to activate or deactivate the service. It is typically associated with short descriptive material presented to the end- 
user, which would potentially be used by the user to decide whether and when to activate the offered service. 

A single service entity can contain multiple distinct multimedia objects or streams, which may need to be provided over 
various MBMS download or MBMS streaming sessions. A download session or a streaming session is associated with 
either an unicast bearer or one or more MBMS bearers and a set of delivery method parameters specifying how content 



£75/ 



3GPP TS 26.346 version 9.1.0 Release 9 



17 



ETSI TS 126 346 V9.1.0 (2010-01) 



is to be received on the mobile side. The MBMS User Service Session may be mapped either on MBMS Bearer 
Services or on unicast bearer services. 

A set of one or more MBMS bearers can be used for deHvering data as part of an MBMS download or streaming 
session. As an example, the audio and visual parts can be carried on separate MBMS bearers. However, it is 
recommendated to transfer MBMS download and/or streaming sessions, which belong to the same MBMS user service 
on the same MBMS bearer service. 

An MBMS bearer (identified by IP multicast address and APN) might be used in providing data to more than one 
MBMS download or streaming session (3GPP TS 22.246 [3], clause 5). 



4.3 



MBMS bearer service architecture 



The MBMS Bearer Service Architecture is defined in 3GPP TS 23.246 [4]. The MBMS User Service interfaces to the 
MBMS system via 3 entities. 

• The BM-SC. 

• The GGSN. 

• The UE. 

The BM-SC provides functions for MBMS user service provisioning and delivery to the content provider. It can also 
serve as an entry point for IP MBMS data traffic from the MBMS User Service source. 

The GGSN serves as an entry point for IP multicast traffic as MBMS data from the BM-SC. 

4.4 Functional Entities to support MBMS User Services 
4.4.1 IVIBIVIS User Service Architecture 

Figure 3 depicts the MBMS network architecture showing MBMS related entities involved in providing MBMS user 
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Figure 3: MBMS network architecture model for GPRS 



£75/ 



3GPP TS 26.346 version 9.1.0 Release 9 



18 



ETSI TS 126 346 V9.1.0 (2010-01) 



MBMS 
Receiver 



X 



MBMS 
Receiver 



UTRAN 



E-UTRAN 



X 



Content 
Provider 



Core Networit , 



MBMS-GW 



SGmb 



BM-SC 



SGi-mb 



IP Network 



Figure 3b: MBMS network architecture model for EPS 

MBMS User Service architecture is based on an MBMS receiver on the UE side and a BM-SC on the network side. 

The use of the Gmb / SGmb and Gi / SGi-mb interface in providing IP multicast traffic and managing MBMS bearer 
sessions is described in detail in 3GPP TS 23.246 [4]. 

Details about the BM-SC functional entities are given in figure 4. 
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Figure 4: BM-SC sub-functional structure 

The Session and Transmission function is further subdivided into the MBMS DeHvery functions and the Associated 
DeHvery functions. 

The BM-SC and UE may exchange service and content related information either over point-to-point bearers or MBMS 
bearers whichever is suitable. To that end the following MBMS procedures are provided: 

• User Service Discovery / Announcement providing service description material to be presented to the end-user 
as well as application parameters used in providing service content to the end-user. 

• MBMS-based delivery of data/content from the BM-SC to the UE over IP multicast or over IP unicast. 

The data/content is optionally confidentiality and/or integrity protected 
The data/content is optionally protected by an forward error correction code 

• Key Request and Registration procedure for receiving keys and key updates. 

• Key distribution procedures whereby the BM-SC distributes key material required to access service data and 
delivered content. 

• Associated Delivery functions are invoked by the UE in relation to the MBMS data transmission. The following 
associated delivery functions are available: 

File repair for download delivery method used to complement missing data. 

Delivery verification and reception statistics collection procedures. 

The interfaces between internal BM-SC functions are outside the scope of the present document. 
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A "Proxy and Transport function" may be located between the "Session and Transmission Function" and the GGSN. 
The "Proxy and Transport function" is transparent to the "Session and Transmission function". The "Proxy and 
Transport" function is defined in sub-clause 5.1.3 of [4]. 

4.4.1a Content Provider / Multicast Broadcast Source 

The Content Provider/Multicast Broadcast Source may provide discrete and continuous media, as well as service 
descriptions and control data, to the BM-SC to offer services at a time. An MBMS User Service may use one or several 
MBMS delivery methods simultaneously. The Content Provider/Multicast Broadcast Source may also be a 3'''^ Party 
Content Provider/Multicast Broadcast Source. 

The Content Provider/Multicast Broadcast Source function may reside within the operator's network or may be 
provided from outside the operator's network. The Content Provider/Multicast Broadcast Source can also configure the 
Session and Transmission functions (e.g. delivery or associated delivery). The interface between the Content 
Provider/Multicast Broadcast Source and the BM-SC is outside the scope of the present document. 

4.4.2 MBMS Key Management Function 

The MBMS Key Management function is used for distributing MBMS keys (Key Distribution subfunction) to 
authorized UEs. Before the UE can receive MBMS keys, the UE needs to register to the Key Request subfunction of the 
Key Management function by indicating the MBMS User Service Id. Once registered, the UE can request missing 
MBMS keys from the BM-SC by indicating the specific MBMS key Id. In order for the UE to stop the BM-SC to send 
MBMS key updates a deregistration with the MBMS User Service Id is needed. 

If the MBMS User Service does not require any MBMS data protection, then the UE shall not register for key 
management purposes. 

A detailed description of all key management procedures is provided in 3GPP TS 33.246 [20]. 

4.4.3 MBMS Session and Transmission Function 

The MBMS Session and Transmission function transfers the actual MBMS session data to the group of MBMS UEs 
using either MBMS Bearer Services or unicast bearer services. The MBMS Session and Transmission function interacts 
with the GGSN (for GPRS) through the Gmb Proxy function to activate and release the MBMS transmission resources. 
The MBMS Session and Transmission function interacts with the MBMS-GW (for EPS) through the SGmb Proxy 
function to activate and release the MBMS transmission resources. 

The session and transmission function may compress headers of MBMS data in some cases. Further, the session and 
transmission function may need to add synchronization information for the MBMS payload e.g. in case of MBSFN 
transmissions. For details on usage of synchronization and header compression see 3GPP TS 23.246 [4] and 3GPP TS 
25.346 [5]. 

The function contains the MBMS delivery methods, which use the MBMS bearer service for distribution of content. 
Further this function contains a set of Associated-Delivery Functions, which may be invoked by the UE in relation to 
the MBMS data transmission (e.g. after the MBMS data transmission). 

The BM-SC Session and Transmission function is further described in later clauses of the present document as well as 
in3GPPTS23.246[4]. 

MBMS user services data may be integrity and/or confidentiality protected as specified within 3GPP TS 33.246 [20], 
and protection is applied between the BM-SC and the UE. This data protection is based on symmetric keys, which are 
shared between the BM-SC and the UEs accessing the service. 

MBMS user services may also be protected against packet loss between BM-SC and UE using a forward error 
correction code. 

4.4.4 User Service Discovery / Announcement function 

The User Service Discovery / Announcement provides service description information, which may be delivered via the 
Session and Transmission function or via the Interactive Announcement function. This includes information, which is 
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necessary to initiate an MBMS user service as described in sub-clause 5.3.1. Metadata for the service descriptions are 
described in sub-clause 5.2. 

4.4.5 Interactive Announcement Function 

An Interactive Announcement Function may offer alternative means to provide service descriptions to the UE using 
HTTP or be distributed through other interactive transport methods. 

4.4.6 MBMS UE 

The MBMS UE hosts the MBMS User Services receiver function. The MBMS receiver function may receive data from 
MBMS bearer services or from unicast bearer services. The MBMS receiver function may receive data from several 
MBMS User Services simultaneously. According to the MBMS UE capabilities, some MBMS UEs may be able to 
receive data belonging to one MBMS User Service from several MBMS Bearer Services simultaneously. The MBMS 
receiver function uses interactive bearers for user service initiation / termination, user service discovery and associated 
delivery procedures. 

In case the MBMS user service is secured, the UE needs one or more cryptographic MBMS service keys, therefore the 
UE requests the relevant cryptographic MBMS service keys using the BM-SC Key Request function. The received keys 
(i.e. MSK) are then used for securing the MBMS session. 

4.5 Usage of identity of MBMS session 

The Session Identity of the MBMS session is provided with the MBMS session start procedure from the BM-SC to the 
GGSN via the Gmb protocol in the MBMS Session Identity information element. The "MBMS Session Identity" 
information element is specified in [77]. The size of the Session Identity field is 1 octet. The MBMS Session Identity is 
forwarded with the MBMS SESSION START REQUEST message through the system and received by the MBMS UE 
with the paging message. 

The usage of the MBMS Session Identity is optional. The MBMS Session Identity is only applicable to MBMS 
download delivery sessions. The MBMS transmission resources are activated as described in sub-clause 5.4. Each 
MBMS session of the MBMS User Service may be activated using a different MBMS session identifier. The MBMS 
UE determines, based on the MBMS Session Identity value, whether the files of the upcoming MBMS download 
session were already received. If the files have already been completely received, the MBMS UE does not respond to 
the notification of the MBMS Session. 

The association of MBMS Session Identities to files is determined by the BM-SC and communicated within the File 
Delivery Table. This association of a MBMS Session Identity to files is valid until a particular expiry time, also 
signalled within the File Delivery Table. If a UE has not received a File Delivery Table associating a given MBMS 
Session Identity to a specific file or set of files, or a previously received association has expired, then the UE shall 
assume that the MBMS Session Identity value is associated to new files which has not yet been received and shall 
respond as normal to MBMS notifications with that Session Identity value. 

A single MBMS Session Identity value may be associated with a single file or with a set of files. Once a MBMS 
Session Identity value has been associated with a particular file or a set of files, this association shall not be changed 
before the expiry of the validity time for that MBMS Session Identity value. In particular, a File Delivery Table 
including some files that has previously been associated with a particular Session Identity value must include all files 
previously associated with that value, even if it is not intended to include all the files within the MBMS transmission 
session. 

An FDT instance includes the MBMS Session Identity expiry time and associates the MBMS Session Identity expiry 
times with particular MBMS Session Identity values. 

If the MBMS Session Identity is used by the BM-SC, the BM-SC shall also provide the session repetition number of 
that MBMS transmission session on the Gmb interface. 

If the BM-SC starts using the MBMS Session Identity for one MBMS Bearer Service, the BM-SC may still decide not 
to use the MBMS Session Identity for a later MBMS transmission on that MBMS bearer service (e.g. when an MBMS 
session is transmitted only once). 
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After determining that all files for a MBMS Session Identity value has been received, the UE shall not respond to 
MBMS notifications for the MBMS Bearer Service with that MBMS Session Identity value until the MBMS Session 
Identity is expired. Once the MBMS Session Id has expired, the content is no longer guaranteed to be repeated, and 
therefore the UE may begin to respond to MBMS notifications for the associated MBMS Bearer Service. 

The BM-SC may send FDT instances on a separate transmission session or interleaved with other data packets of the 
same transmission session. An FDT instance may describe more files than the files to be transmitted over the same 
transmission session as that FDT instance. 

4.6 Time Synchronization between the BIVI-SC and IVIBIVIS UEs 

A number of MBMS metadata fragments and File Delivery Table (FDT) contain NTP encoded time values. NTP uses 
UTC as reference time and is independent from time zones. In order to process the time information from the BM-SC 
correctly, the MBMS UEs shall be time synchronized with the BM-SC with a tolerance of H-/- 10 seconds. The BM-SC 
shall offer an SNTP time server. The MBMS UEs should use SNTP to synchronize the time with the BM-SC. The 
MBMS UE should not use the SNTP time synchronization service more often than once in 30 days to avoid scalability 
issues. 

The BM-SC shall support the SNTP anycast mode [84]. An anycast client in the MBMS UE sends a request to a 
designated IPv4 or IPv6 local broadcast address or multicast group address. One or more SNTP anycast servers reply 
and include a timestamp with their current time and its precision. BM-SC SNTP servers shall only respond if they have 
a valid synchronisation time and shall not leave the timestamp blank, such that the SNTP Leap Indicator (LI) field shall 
not use the value 3 (warning: unsynchronised). Any MBMS SNTP client shall use the anycast mode each time it 
performs SNTP synchronisation; the client does not need to keep server address state data and changes in the SNTP 
server addressing will not affect each subsequent synchronisation operation. 

For IPv4, the Internet Assigned Numbers Authority (lANA) has assigned the multicast group address 224.0. LI for 
NTP, which is used by both multicast servers and anycast clients. For IPv6, the lANA has assigned the multicast group 
address FF0X:0:0:0:0:0:0:101. These NTP assignments apply to SNTP usage as well. The SNTP server will join these 
IP multicast groups. 



5 Procedures and protocols 

5.1 Introduction 

This clause specifies the MBMS User service procedures and protocols. 

5.2 User Service Discovery/Announcement 
5.2.1 Introduction 

User service discovery refers to methods for the UE to obtain a list of available MBMS user services or user service 
bundles along with information on the user services. Part of the information may be presented to the user to enable 
service selection. 

User service announcement refers to methods for the MBMS service provider to announce the list of available MBMS 
user services and user service bundles, along with information on the user services, to the UE. 

In order for the user to be able to initiate a particular service, the UE needs certain metadata information. The required 
metadata information is described in sub-clause 5.2.2. 

According to 3GPP TS 23.246 [4], in order for this information to be available to the UE operators/service providers 
may consider several service discovery mechanisms. User service announcement may be performed over a MBMS 
bearer or via other means. The download delivery method is used for the user service announcement over a MBMS 
bearer. The user service announcement mechanism based on the download delivery method is described in sub-clause 
5.2.3. The user service announcement using interactive announcement function is described in sub-clause 5.2.4. Other 
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user service announcement and discovery mechanisms by other means than the download dehvery method are out of 
scope of the present document. 

5.2.2 MBMS User Service Description Metadata Fragments 
5.2.2.1 Introduction 

MBMS User Service Discovery/ Announcement is needed in order to advertise MBMS Streaming and MBMS 
Download User Services and User Service Bundles in advance of, and potentially during, the User Service sessions 
described. The User Services are described by metadata (objects/files) delivered using the download delivery method as 
defined in clause 7 or using interactive announcement functions. 

MBMS User Service Discovery/ Announcement involves the delivery of fragments of metadata to many receivers in a 
suitable manner. The metadata itself describes details of services. A metadata fragment is a single uniquely identifiable 
block of metadata. An obvious example of a metadata fragment would be a single SDP file ([14]). 

The metadata consists of: 

• a metadata fragment object describing details of a single or a bundle of MBMS user services (defined in sub- 
clause 11.2); 

• a metadata fragment object(s) describing details of MBMS user service sessions (defined in sub-clause 7.3 and 
8.3); 

• a metadata fragment object(s) describing details of Associated delivery methods (defined in sub-clause 9.5); 

• a metadata fragment object(s) describing details of service protection (defined in sub-clause 1 1.3); 

• a metadata fragment object describing details of the FEC repair data stream. 
Metadata management information consists of: 

• a metadata envelope object(s) allowing the identification, versioning, update and temporal validity of a metadata 
fragment (defined in sub-clause 11.1). 

The metadata envelope and metadata fragment objects are transported as file objects in the same download session 
either as separate referencing files or as a single embedding file - see sub-clause 5.2.3.3. A single metadata envelope 
shall describe a single metadata fragment, and thus instances of the two are paired. A service announcement sender 
shall make a metadata envelope instance available for each metadata fragment instance. The creation and use of both 
an embedded envelope instance and a referenced envelope instance for a particular fragment instance is not 
recommended. 

The metadata envelope and metadata fragment objects may be compressed using the generic GZip algorithm specified 
in RFC 1952 [42] as content/transport encoding for transmission. Where used over an MBMS bearer, this shall be 
according to Download delivery content encoding using FLUTE - see sub-clause 7.2.5. 
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Figure 5: Simple Description Data Model 

Figure 5 illustrates the simple data model relation between these description instances using UML [21] for a single User 
Service Bundle Description. 

NOTE: "N" means any number in each instance. 

One MBMS User Service Bundle Description shall contain at least one User Service Description instance and may 
contain several. The User Service Bundle Description may refer to a single FEC Repair Stream Description. 

One MBMS User Service Description instance shall include at least one delivery method description instance. The 
delivery method description shall refer to one session description instance. 

The delivery method description may contain references to a service protection description and an associated delivery 
procedure description. Several delivery methods may reference the same service protection description. 

If the associated delivery procedure description is present in the user service description instance, it may be referenced 
by one or more delivery methods. 

An MBMS user service description allows the association of delivery methods to one or more access systems. The 
association is used to describe the use of separate access systems for the same MBMS user service. One delivery 
method may be offered throughout one or more radio access systems. The use of separate MBMS bearer services for the 
same MBMS user service is described in sub-clause 5.1.5.2 of [4]. 

Multipart MIME [37] may be used to concatenate the descriptions into one document for transport. 



5.2.2.2 



Session Description 



One or more session descriptions are contained in one session description object. The session description instance shall 
be formatted according to the Session Description Protocol (SDP) [14]. Each session description instance must describe 
either one Streaming session or one FLUTE Download session. A session description for a Streaming session may 
include multiple media descriptions for RTF sessions. The sessionDescriptionURI references the session description 
object. The session description is specified in sub-clause 7.3 for the MBMS download delivery method and in subclause 
8.3 for the MBMS streaming delivery method. 
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5.2.2.3 Associated Delivery Procedure Description 

The description and configuration of associated delivery procedures is specified in clause 9. The 
associatedProcedureDescriptionllRI references the associated delivery procedure instance. 

An associated delivery procedure description may be delivered on a dedicated announcement channel and updated on a 
dedicated announcement channel as well as in-band with an MBMS download session. 

If an associated delivery procedure description for File-Repair operations is available, then the MBMS receiver may use 
the file repair service as specified in sub -clause 9.3. 

If an associated delivery procedure description for reception reporting is available, then the MBMS receiver shall 
provide reception reports as specified in sub-clause 9.4. 

5.2.2.4 Service Protection Description 

The security description fragment contains the key identifiers and procedure descriptions for one delivery method. 
When different delivery methods use the same security description, the same security description document is 
referenced from the different delivery method elements. 

The security description contains key identifiers and the server address to request the actual key material. To avoid 
overload situations, the same load balancing principles as in the associated delivery procedures are used. The key 
management server shall be selected as defined in sub-clause 9.3.5. The back-off time shall be determined as defined in 
sub-clause 9.3.4. 

The XML schema for the service protection description is defined in sub-clause 1 1.3. 



5.2.2.5 FEC Repair Stream Description 

The streaming delivery method's FEC has separate stream for repair data, which is described by the FEC Repair Stream 
Description. The FEC Repair Stream Description shall be done using SDP [14]. This SDP file is referenced by the 
bundleDescription element in the service description. The FEC Repair Stream described is common for all FEC 
protected packet flows within the MBMS User Service Bundle Description instance. 

5.2.3 User Service Announcement over a MBMS bearer 

5.2.3.1 General 

Both the metadata envelope and metadata fragment objects are transported as file objects in the same download session. 

To receive a Service Announcement User Service the client shall obtain the session parameters for the related MBMS 
download session transport. This may be using a separate Service Announcement session. 

NOTE: The user service announcements are not protected when sent over MBMS bearer. See 
3GPP TS 33.246 [20] 

5.2.3.2 Metadata Envelope Transport 

The metadata envelope object is transported as a file object in the same MBMS service announcement download 
session as its metadata fragment file object (i.e. in-band with the metadata fragment session). 

5.2.3.3 Metadata Envelope and Metadata Fragment Association with FLUTE 

The MBMS Download service announcement session FDT Instances provide URIs for each transported object. The 
metadata envelope metadatallRI field shall use the same URI for the metadata fragment as is used in the FDT Instances 
for that metadata fragment file. Thus, the fragment can be mapped to its associated envelope in-band of a single MBMS 
download session. 

In the referencing case, each metadata envelope and corresponding metadata fragment shall be grouped together by the 
FDT using the grouping mechanism described in sub-clause 7.2.5. This reduces the complexity of requesting both 
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fragment and envelope for each pair, thus it is recommended that only the metadata fragment (fileURI) be requested 
from the download client (which will result in both fragment and envelope being received using the grouping 
mechanism). 

5.2.4 User Service Announcement using Interactive Announcement 
Function 

User service descriptions may be transported to the UE using HTTP and other interactive transport methods. A BM-SC 
may provide the service descriptions on request. Further protocol specifications of interactive announcement functions 
are outside of the scope of this specification. 

Aggregated MBMS service announcement documents as specified in sub-clause 5.2.5 may be used with the interactive 
announcement functions. UEs shall support the disassembly of aggregated MBMS service announcement documents. 
UEs shall support Gzip decoding of MBMS service description objects for interactive transport (BM-SC use of Gzip is 
optional in accordance with sub-clause 5.2.2). 

The BM-SC may use Metadata Envelopes as described in clause 11.1, and UEs shall support their use with the 
Interactive Announcement Function. Where metadata envelopes are not used, only the latest delivery of a metadata 
fragment shall be used by the UE, and the BM-SC shall ensure timely, consistent, size-limited and secure delivery of 
metadata by means outside the scope of this document. 

5.2.5 User Service Announcement over point-to-point pusin bearers. 

5.2.5.1 General 

User service announcement over point-to-point push bearers have several characteristics that differ from user service 
announcement over a MBMS bearer. It is not essential that the metadata envelope made available by the service 
announcement sender is transmitted to the MBMS terminal. In the case that both the metadata envelope and metadata 
fragment objects are transported, it is a limitation of the solution that the metadata fragment must either be embedded 
within the metadata envelope, or that the metadata fragment must be referenced by the metadata envelope and they are 
both contained within a multipart MIME container [37]. In either configuration, both the metadata envelope and the 
metadata fragment objects are transported as file objects in the same download session. 

This sub-clause covers both metadata transport and metadata fragmentation aspects of Service Announcement. Service 
Announcement over point-to-point push bearers is specified. 

NOTE: The user service announcements are not protected when sent over point-to-point push bearers. See 
3GPPTS 33.246 [20]. 

5.2.5.2 Supported Metadata Syntaxes 

The supported metadata syntaxes are as defined in sub-clause 11.1 of this document. 

5.2.5.3 Consistency Control and Syntax Independence 

The consistency control and syntax independence is as defined in sub-clause 11.1 of this document. 

5.2.5.4 Metadata Envelope Definition 

The metadata envelope definition is as defined in sub-clause 11.1 of this document. 

5.2.5.5 Delivery of the Metadata Envelope 

An instance of metadata fragment shall either be embedded within the metadata envelope or be included in a multipart 
MIME container together with the envelope. The envelope and fragment are, by definition, transported together and in- 
band of the same transport session. 

The Metadata Envelope includes a reference {metadataURI) to the associated metadata fragment using the same URI as 
the fragment file is identified by in the Service Announcement. Thus, Metadata Envelope can be mapped to its 
associated metadata fragment. 
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5.2.5.6 Metadata Envelope Transport 

The metadata envelope object is transported as a file object in the same MBMS service announcement download 
session as its metadata fragment file object (i.e. in-band with the metadata fragment session). 

5.2.5.7 User service announcement over SMS bearers 

User service announcements over SMS bearers are formatted according to the OMA Push OTA specification [79]. 

OTA-WSP shall be used over the SMS bearer. Application port addressing shall be used as specified in [79]. The 
appHcation ID to be used is 0x9023 as allocated by OMNA [85]. 

Either confirmed or unconfirmed push may be used. In either case, the primitive shall contain the Push Headers 
parameter. Within this parameter, the Content-Type header shall be included and the Content-Encoding header shall be 
included if GZip is used. 

5.2.5.8 User service announcement over HTTP push bearers 

User service announcements over HTTP push bearers are formatted according to the OMA Push OTA specification 
[79]. 

OTA-HTTP shall be used over the HTTP push bearer. Application port addressing shall be used as specified in [79]. 
The application ID to be used is 0x9023 as allocated by OMNA [85]. 

The Content-Encoding header shall be included if GZip is used. 

5.2.6 Metadata Fragment Encapsulation to aggregate Service 
Announcement Documents 

The present document defines a number of metadata fragments to describe MBMS user services. A metadata fragment 
is a single uniquely identifiable block of metadata. Generally, more than one metadata fragment is necessary to provide 
all necessary parameters to initiate an MBMS User Service. Typically, metadata fragments are provided in separate 
documents. Each metadata fragment is labelled with its MIME type. 

Multipart MIME may be used to encapsulate metadata fragments into an aggregate service announcement document. 
The aggregate document may contain metadata fragments of several MBMS user services. It is recommended, that any 
such aggregate service announcement document contains all the referenced metadata fragments of each MBMS user 
service description it contains (i.e. in the same multipart MIME structure). 

An aggregate service announcement document shall encapsulate metadata fragments according to RFC 2557 [37]. The 
first encapsulated file of an aggregate service announcement document is the root resource. The root resource shall be 
either an MBMS user service description or a metadata envelope (as a referencing index). The service description 
metadata is defined in sub-clause 5.2.2.4. The metadata envelope is defined in sub-clause 5.2.3.3. 

The type field of the multipart/related header shall be set to application/mbms-user-service-description-parameter in 
case the root resource is a user service description instance. The type field of the multipart/related header shall be set to 
application/mbms -envelope in case the root resource is a metadata envelope. 

5.2.7 Registration and Deregistration Procedure for MBMS User Service 
Consumption 

The MBMS User Service Description Fragment may include a registration description. If the registration description is 
present in the MBMS User Service Description Fragment, then the UE shall use the registration and deregistration 
procedures as defined in this section. 

A registration request is then initiated by the UE, in order to receive the complete user service description. The 
registration procedure is performed using HTTP 1.1 [18] POST message towards the indicated RegistrationURL. 

A successful registration response shall start with a 200 OK status line in the response header and shall contain in the 
body the metadata fragments that are referenced by the USD in a multipart MIME container. 
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The registration request shall be formatted according to the following XML schema and using the RegistrationRequest 
element. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 .org/2 00 1/XMLSchema" 

xmlns=" urn: 3GPP : metadata : 2 008 :MBMS : Registration" 

elementFormDefault=" qualified" 

targetNamespace=" urn: 3GPP :metadata : 2008 :MBMS : Registration" > 

<xs : element name="RegistrationOperationRequest" > 
<xs : complexType> 
<xs : choice> 

<xs : element name=" RegistrationRequest" type="RegistrationOperationRequestType"/> 
<xs : element name="DeregistrationRequest" type ="Regist rat ionOperationRequestType"/> 
</xs : choice> 
</xs : complexType> 
</xs : element> 

<xs : complexType name="RegistrationOperationRequestType" > 

<xs : attribute name="IMEI" type="xs : string" use="optional"/> 

<xs : attribute name="MSISDN" type="xs : string" use="required"/> 

<xs : attribute name="ServiceID" type="xs : anyURI" use="required"/> 

<xs : anyAttribute namespace="##any" processContents="lax"/> 
</xs : complexType> 

</xs : schema> 

A de-registration procedure is used by the UE to de-register at the end of the user service consumption, in case a 
registration procedure has been performed. The de-registration request shall be sent to a registration server (preferably 
the one with which the registration procedure has been performed). The de-registration procedure consists of sending an 
HTTP 1 . 1 POST request with an XML body formatted according to the XML schema above, using the 
DeregistrationRequest element. 

The MIME type of the message body of the registration and deregistration request shall be set to "text/xml". 

The IMEI element contains, if present, the International Mobile Equirment Identifier as defined in [77]. 

The MSISDN element contains the Mobile Subscriber ISDN Number as defined in [77]. 

The ServicelD element contains the unique MBMS User Service Identifier as defined in clause H .2. L L 

5.3 User Service Initiation/Termination 

5.3.1 Initiation of MBMS Bearer Service based Services 

MBMS User Service initiation refers to UE mechanisms to set-up the reception of MBMS user service data. During the 
User Service Initiation procedure, a set of MBMS Bearers may be activated. The User Service Initiation procedure takes 
place after the discovery of the MBMS user service. 
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Figure 6: Initiation of an MBMS User Service 

1 . The User Service Initiation Procedure is triggered and takes a User Service Description as input that has been 
obtained e.g. by executing the MBMS User Service discovery and announcement functions. 

2. The MBMS UE registers to the MBMS User Service, if registration is required for the MBMS User Service. If 
security functions are activated for the MBMS User Service, the MBMS UE requests MBMS service keys. The 
keys are sent to the UE, after the user is authorized to receive the MBMS service. The request shall be 
authenticated. Details on the MBMS User Service Registration procedure are described in 3GPP TS 33.246 
[20]. 

3. The MBMS UE uses the MBMS activation procedure to activate the MBMS Bearer Service. The MBMS 
activation procedure is the MBMS Multicast Service activation procedure and the MBMS Broadcast activation 
procedure as defined in 3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is activated, there is no 
activation message sent from the UE to the BM-SC. The activation is locally in the UE. Note that the MBMS 
Bearer Services may already be active and in use by another MBMS User Service. 

3n. In case the MBMS User Service uses several MBMS Bearer Services, the User Service Description contains 
several description items. In that case, the MBMS receiver function repeats the activation procedure for each 
MBMS Bearer Service as described in 3. 

5.3.2 Termination of MBMS Bearer Service based Services 

MBMS user service termination refers to the UE mechanisms to terminate the reception of MBMS user services. A set 
of MBMS Bearers may be deactivated during this procedure. 
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Figure 7: Termination of an lUIBIUIS user service 

1 . The User Service termination Procedure is triggered. A reference to the User Service to terminate is provided 
as parameter. 

2. The MBMS UE deregisters, when registration was required for the MBMS User Service. If security functions 
are activated for the MBMS User Service, the MBMS UE deregisteres the security association for the MBMS 
User Services. Details on the MBMS User Service Deregistration procedure are described in 3GPP TS 33.246 
[20]. 

3. If no other MBMS User Service uses the MBMS Bearer service, the MBMS UE uses the MBMS deactivation 
procedure to deactivate the MBMS Bearer Services. The MBMS deactivation procedure represents the MBMS 
Multicast service deactivation procedure and the MBMS Broadcast deactivation procedure as described in 
3GPP TS 23.246 [4]. In case the MBMS Broadcast Mode is deactivated, there is no message sent to the 
BM-SC. The deactivation is only locally in the UE. 

3n. In case the MBMS User Service uses several Bearer Services, the UE repeats the deactivation procedure for 
each Bearer Service as described in 3. 

5.3.3 Initiation of Unicast Bearer Service based Services 

Unicast Bearer Service based MBMS User Service initiation refers to the mechanisms to set-up the reception of MBMS 
user service data via a UMTS Bearer Service with interactive and/or streaming straffic class. 

In case of the initiation of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS 
Download delivery method, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be 
used. The establishement of a PSS session is described in clause 5.1 of 3GPP TS 26.234 [47]. 

In case of the initiation of a MBMS Download delivery method, the MBMS UE is registered in the BM-SC for OMA- 
PUSH based reception of the files with the BM-SC. 

5.3.4 Termination of Unicast Bearer Service based Services 

Unicast Bearer Service based MBMS user service termination refers to the mechanisms to terminate the reception of 
MBMS user service data via a UMTS Bearer Service with interactive and/or streaming straffic class. 

In case of the termination of a MBMS Streaming delivery method or a combined MBMS Streaming and MBMS 
Download delivery method, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be 
used. The termination of a PSS session is described in clause 5.3 of 3GPP TS 26.234 [47]. 

In case of the termination of a MBMS Download delivery method, the MBMS UE is deregistered in the BM-SC so that 
the OMA-PUSH based reception of the files with the BM-SC will be terminated. 
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5.3.5 Scalable Service Initiation and Termination for MBMS Services 

5.3.5.1 General 

MBMS service initiation and termination as defined in clauses 5.3.1 to 5.3.4 may consist of network interactions such 
as sending an IGMP Join or Leave message to the network as described in sections 8.2 and 8.7 of 3GPP TS 23.246 [4]. 
Initiation and termination procedures may be triggered at the MBMS UE by the user or be scheduled to happen 
automatically. Upon (or after) receiving a user service announcement, the MBMS UE may render the information about 
the advertised services to the user to assist him in the service selection. The user may decide to receive a given service 
and hence trigger the service initiation procedure. Alternatively, the user may declare his interest in a specific service a- 
priori and upon receiving the service announcement for that specific service, the MBMS UE may schedule the initiation 
procedure at or around the start time of the session. Similarly, the MBMS UE may schedule the termination procedure 
at or around the session end time. 

As a consequence, MBMS UEs may be oriented to start their service initiation and termination procedures at the same 
time or during a relatively short period. This may cause network congestion, especially during the multicast of a popular 
service, as all MBMS UEs may be time synchronized. 

5.3.5.2 Randomization of Service Initiation over Time 

The MBMS User Service description may contain parameters to uniformly randomize the User Service Initiation 
procedures of the MBMS UEs. Security functions may be part of the User Service Initiation procedure as defined in 
clause 5.3.1. If a user service initiation randomization is defined for a user service, then the overload prevention 
definition in the service protection description shall be ignored for the service initiation. For randomizing the time of the 
initiation procedure, the MBMS UE shall understand the following parameters, which may be signalled by the BM-SC 
in the MBMS user service description as described in section 1 1.2.1: 

1 . initiationStartTime parameter is used by the BM-SC to signal to the MBMS UE the start time for the User 
Service Initiation procedure randomization period. If the initiationStartTime parameter is not present, the 
MBMS UE uses the time of the Service Annoucement reception as the start time. 

2. protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical time 
periods, during which congestion shall be avoided. The MBMS UEs shall randomly spread the initiation 
procedure using the randomTimePeriod during this protection period. 

3. randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval 
over which initiation procedures shall be randomly deferred. The MBMS UE calculates a random time out of 
the randomTimePeriod interval to defer the execution of the initiation procedure. 

The MBMS UE shall start its initiation procedure immediately if the procedure is triggered outside of protection 
periods. 

5.3.5.3 Randomization of Service Termination over Time 

The MBMS User Service description may contain parameters to uniformly randomize the User Service Termination 
procedures of the MBMS UEs. For randomizing the time of the termination procedure, the MBMS UE shall understand 
the following parameters, which may be signalled by the BM-SC in the MBMS USD as described in section 11. 2.1: 

1 . protectionPeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of the critical 
time period, during which congestion needs to be avoided. The MBMS UEs shall randomly spread the 
termination procedure using the randomTimePeriod during this period and starting from the session end 
time. 

2. randomTimePeriod parameter is used by the BM-SC to signal to the MBMS UE the duration of an interval 
over which termination procedures shall be randomly deferred. The termination procedure is only 
randomized during the protectionPeriod. 

If the termination procedure is triggered before the session end time or after the protection period end time, the MBMS 
UE shall start its termination procedure immediately. If it is in a protection period, the MBMS UE shall defer its 
termination procedure to a random time spread over an interval of duration randomTimePeriod. 
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5.4.1 MBMS Data Transfer Procedure using MBMS Bearer Services 

MBMS Data Transfer procedure using MBMS Bearer Services refers to the network (and UE) mechanism to transfer 
(and receive) data for one MBMS User Service on one or several MBMS Bearer Services. 
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Figure 8: Procedure of MBMS Data Transfer 

1 . The MBMS DeHvery Method for the MBMS User Service is triggered by the MBMS User Service 
Provider. Note, details of the trigger are beyond of the present document. 

2. - 2n. The MBMS Delivery function uses the MBMS Session Start Procedure to the GGSN and/or MBMS-GW, 

possibly through the Gmb Proxy and/or the SGmb Proxy function to activate all MBMS Bearer Services, 
which belong to the MBMS User Service. The MBMS Bearer service to be activated is uniquely identified 
by the TMGI. 

Note. MBMS Bearer services might be activated only to a subset of the available access systems (see 3GPP TS 
23.246 [4]). In case MBMS User Services or delivery methods are not available throughout all access 
systems, the BM-SC describes this transmission strategy in the MBMS User Service Description (see 
sub-clause 5.2.2). 

3. - 3n. The data of the MBMS user service are transmitted to all Hstening MBMS UEs. Several MBMS Bearer 

services may be used to transmit the MBMS user service data. MBMS user service data may be integrity 
and/or confidentiality protected. In case MBMS user service data are integrity and/or confidentiality 
protected, MBMS traffic keys are delivered simultaneously on the same or a different MBMS bearer. 
Optionally, syncronization information for MBSFN may be added to the MBMS User Data. The headers of 
MBMS User data may optionally be compressed (see 3GPP TS 23.246 [4] and TS 25.346 [5]) 

4. - 4n. The MBMS Delivery function uses the MBMS Session Stop procedure to trigger the GGSN, possibly 

through the Gmb Proxy function to release all MBMS Bearer Service for this User Service. A unique 
identifier for the MBMS Bearer service to be deactivated (i.e. the TMGI) is passed on as a parameter. 

5. In case associated delivery procedures are allowed or requested for an MBMS User Service, the MBMS UE 
sends an associated-delivery procedure request to the associated -delivery function. The BM-SC may 
authenticate the user. See 3GPP TS 33.246 [20]. The MBMS UE may need to wait a random time before it 
starts the associated delivery procedure according to clause 9. 
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5.4.2 MBMS Data Transfer Procedure using other UMTS Bearer Services 

MBMS Data Transfer procedure using other UMTS Bearer Services refers to the network (and UE) mechanism to 
transfer (and receive) data for one MBMS User Service on one or more Unicast Bearer Services. 

In case the MBMS Data belong to a MBMS Streaming delivery session or a combined MBMS Streaming and MBMS 
Download delivery session, the Packet Switched Streaming Service (PSS) as defined in 3GPP TS 26.234 [47] shall be 
used. 

In case the MBMS Data belong to a MBMS Download delivery session, the MBMS data is transferred using OMA- 
PUSH. 



5.5 



MBMS Protocols 



Figure 9 illustrates the protocol stack used by MBMS User services. The grey-shaded protocols and functions are 
outside of the scope of the present document. MBMS security functions and the usage of HTTP-digest and SRTP are 
defined in 3GPP TS 33.246 [20]. 
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Figure 9: Protocol stack view of the MBMS User Services 



Introduction on Delivery Methods 



Two delivery methods are defined in the present document - the download delivery method and the streaming delivery 
method. MBMS delivery methods make use of MBMS bearers for content delivery but may also use the associated 
procedures defined in clause 9. 

Use of MBMS bearers by the download delivery method is described in clause 7. The File Repair Procedure and the 
Reception Reporting Procedure (described in clause 9) may be used by the download delivery method. 

Use of MBMS bearers by the streaming delivery method is described in clause 8. 



Download Delivery Method 



7.1 



Introduction 



MBMS download delivery method uses the FLUTE protocol (RFC 3926 [9]) when delivering content over MBMS 
bearers. MBMS download delivery method may use OMA PUSH [79] when delivering content over other UMTS 
bearers. Usage of FLUTE protocol is described in clause 7.2. The Usage of OMA Push is described in clasue 7.4. The 
FLUTE session set-up with RTSP is defined in clause 7.5. 

FLUTE is built on top of the Asynchronous Layered Coding (ALC) protocol instantiation (RFC 3450 [10]). ALC 
combines the Layered Coding Transport (LCT) building block [11], a congestion control building block and the 
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Forward Error Correction (FEC) building block ([12]) to provide congestion controlled reliable asynchronous delivery 
of content to an unlimited number of concurrent receivers from a single sender. As mentioned in (RFC 3450 [10]), 
congestion control is not appropriate in the type of environment that MBMS download delivery is provided, and thus 
congestion control is not used for MBMS download delivery. See figure 10 for an illustration of FLUTE building block 
structure. FLUTE is carried over UDP/IP, and is independent of the IP version and the underlying link layers used. 



FLUTE 



LCT 



ALC 
CC i FEC " 



Figure 10: Building block structure of FLUTE 

ALC uses the LCT building block to provide in-band session management functionality. The LCT building block has 
several specified and under-specified fields that are inherited and further specified by ALC. ALC uses the FEC building 
block to provide reliability. The FEC building block allows the choice of an appropriate FEC code to be used within 
ALC, including using the no-code FEC code that simply sends the original data using no FEC coding. ALC is under- 
specified and generally transports binary objects of finite or indeterminate length. FLUTE is a fully-specified protocol 
to transport files (any kind of discrete binary object), and uses special purpose objects - the File Description Table 
(FDT) Instances - to provide a running index of files and their essential reception parameters in-band of a FLUTE 
session. 

7.2 FLUTE usage for MBMS download 

The purpose of download is to deliver content in files. In the context of MBMS download, a file contains any type of 
MBMS data (e.g. 3GPP file (AudioA'ideo), Binary data. Still images. Text, Service Announcement metadata). 

In the present document the term "file" is used for all objects carried by FLUTE (with the exception of the FDT 
Instances). 

UE applications for MBMS user services built upon the download delivery method have three general approaches to 
getting files from the FLUTE receiver for a joined session: 

• Promiscuous: Instruct FLUTE to promiscuously receive all files available. Promiscuous reception can be 
suitable for single purpose sessions (generally with limited number and/or size of files) although uncertainty over 
the quality and content of files makes this approach generally undesirable. 

• One-copy: Instruct FLUTE to receive a copy of one or more specific files (identified by the fileURI) - and 
potentially leaving the session following reception of one copy of all the specified files. Specifying the download 
file ensures that the UE has an upper bound to the quantity of files downloaded. One-copy reception requires 
prior knowledge of the file identifiers (fileURIs). 

• Keep-updated: Instruct FLUTE to receive one or more specific files and continue to receive any updates to 
those files. As with one-copy, the keep-updated approach bounds the quantity of files downloaded and requires 
prior knowledge of the file identifiers. 

NOTE: The present document does not prevent or endorse changing download reception approach, and any 

related file list, during the life of the download session. Discovery of session content lists (including file 
lists) out-of-band of the delivery method sessions is beyond the scope of the present document. 

The interaction of these file download modes and the caching directives is defined in section 7.2.13. 

MBMS clients and servers supporting MBMS download shall implement the FLUTE specification (RFC 3926 [9]), as 
well as ALC (RFC 3450 [10]) and LCT (RFC 3451 [11]) features that FLUTE inherits. In addition, several optional and 
extended aspects of FLUTE ,as described in the following clauses, shall be supported. 
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One FDT instance is typically bound to one MBMS transmission session. It is therefore recommended, that each 
MBMS transmission session should contain one or more repetitions of the same FDT instance. 

7.2.1 Fragmentation of Files 

Fragmentation of files shall be provided by a blocking algorithm (which calculates source blocks from source files) and 
a symbol encoding algorithm (which calculates encoding symbols from source blocks). 

7.2.2 Symbol Encoding Algorithm 

The "Compact No-Code FEC scheme" - [12] (FEC Encoding ID 0, also known as "Null-EEC") shall be supported. 

The Raptor FEC scheme is described in sub-clause 7.2.12. 

A UE that supports MBMS User Services shall support a decoder for the Raptor FEC scheme. 

If a UE that supports MBMS User Services receives a mathematically sufficient set of encoding symbols generated 
according to the encoder specification in [91] for reconstruction of a source block then the decoder shall recover the 
entire source block. Note that the example decoder described in [91] clause 5.5 fulfils this requirement. 

7.2.3 Blocking Algorithm 

In the case of the Compact No-Code FEC scheme [12] (FEC Encoding ID 0), then the "Algorithm for Computing 
Source Block Structure" described within the FLUTE specification (RFC 3926 [9]) shall be used. 

In the case of Raptor forward error correction, then the algorithm defined in [91] shall be used. 

The values of A^, Z, TandA shall be set such that the sub-block size is less than 256KB. 

7.2.4 Congestion Control 

For simplicity of congestion control, FLUTE channelization shall be provided by a single FLUTE channel with single 
rate transport. 

7.2.5 Content Encoding of Files for Transport 

Files may be content encoded for transport, as described in [9], in the Download delivery method using the generic 
GZip algorithm as specified in RFC 1952 [42]. UEs shall support GZip content decoding of FLUTE files (GZIP RFC 
1952 [42], clause 9). 



7.2.6 Transport File Grouping 



Files downloaded as part of a multiple-file delivery are generally related to one another. Examples include web pages, 
software packages, and the referencing metadata envelopes and their metadata fragments. FLUTE clients analyse the 
XML-encoded FDT Instances as they are received, identify each requested file, associate it with FLUTE packets (using 
the TOI) and discover the relevant in-band download configuration parameters of each file. 

An additional "group" field in the FLUTE FDT instance and file elements enables logical grouping of related files. A 
FLUTE receiver should download all the files belonging to all groups where one or more of the files of those groups 
have been requested. However, a UE may instruct its FLUTE receiver to ignore grouping to deal with special 
circumstances, such as low storage availability. 

The group names are allocated by the FLUTE sender and each specific group name shall group the corresponding files 
together as one group, including files describes in the same and other FDT Instances, for a session. 

Group field usage in FDT Instances is shown in the FDT XML schema (clause 7.2.10). Each file element of an FDT 
Instance may be labelled with zero, one or more group names. Each FDT Instance element may be labelled with zero, 
one or more group names which are inherited by all files described in that FDT Instance. 
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7.2.7 Signalling of Parameters with Basic ALC/FLUTE Headers 

FLUTE and ALC mandatory header fields shall be as specified in [9, 10] with the following additional specializations: 

• The length of the CCI (Congestion Control Identifier) field shall be 32 bits and it is assigned a value of zero 
(C=0). 

• The Transmission Session Identifier (TSI) field shall be of length 16 bits (S=0, H=l, 16 bits). 

• The Transport Object Identifier (TOI) field should be of length 16 bits (0=0, H=l). 

• Only Transport Object Identifier (TOI) (zero) shall be used for FDT Instances. 

• The following features may be used for signalling the end of session and end of object transmission to the 
receiver: 

The Close Session flag (A) for indicating the end of a session. 

The Close Object flag (B) for indicating the end of an object. 

In FLUTE the following applies: 

• The Sender Current Time present flag (T) shall be set to zero. 

• The Expected Residual Time present flag (R) shall be set to zero. 

• The LCT header length (HDR_LEN) shall be set to the total length of the LCT header in units of 32-bit words. 

• For "Compact No-Code EEC scheme" [12], the EEC Payload ID shall be set according to RFC 3695 [13] such 
that a 16 bit SBN (Source Block Number) and then the 16 bit ESI (Encoding Symbol ID) are given. 

• For "MBMS EEC scheme", the EEC Payload ID shall be set according to Section 7.2.10 below. 

7.2.8 Signalling of Parameters with FLUTE Extension Headers 

FLUTE extension header fields EXT_FDT, EXT_FTI , EXT_CENC [9] shall be used as follows: 

• EXT_FTI shall be included in every FLUTE packet carrying symbols belonging to any FDT Instance. 

• FLUTE packets carrying symbols of files (not FDT Instances) shall not include an EXT_FTI. 

• FDT Instances shall not be content encoded and therefore EXT_CENC shall not be used. 
In FLUTE the following applies: 

• EXT_FDT is in every FLUTE packet carrying symbols belonging to any FDT Instance. 

• FLUTE packets carrying symbols of files (not FDT instances) do not include the EXT_FDT. 

7.2.9 Signalling of Parameters with FDT Instances 

The extended FLUTE FDT instance schema defined in clause 7.2.10.1 (based on the one in RFC 3926 [9]) shall be 
used. In addition, the following applies to both the session level information and all files of a FLUTE session. 

The inclusion of these FDT Instance data elements is mandatory according to the FLUTE specification: 

• Content-Location (URI of a file). 

• TOI (Transport Object Identifier of a file instance). 

• Expires (expiry data for the FDT Instance). 

Additionally, the inclusion of these FDT Instance data elements is mandatory. Note the following elements are optional 
in the FDT schema to stay aligned with the IETF RFC defined schema: 
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• Content-Length (source file length in bytes). 

• Content-Type (content MIME type). 

• FEC Encoding ID. 

Other FEC Object Transmission Information specified by the FEC scheme in use: 

NOTE: The FEC Object Transmission Information elements used are dependent on the FEC scheme, as indicated by 
the FEC Encoding ID. 

• FEC-OTI-Maximum-Source-Block-Length. 

• FEC-OTI-Encoding-Symbol-Length. 

• FEC-OTI-Max-Number-of-Encoding-Symbols. 

• FEC-OTI-Scheme-Specific-Info. 

NOTE 1 : RFC 3926 [9] describes which part or parts of an FDT Instance may be used to provide these data 
elements. 

These optional FDT Instance data elements may or may not be included for FLUTE in MBMS: 

• Complete (the signalling that an FDT Instance provides a complete, and subsequently unmodifiable, set of file 
parameters for a FLUTE session may or may not be performed according to this method). 

• Content-Encoding. 

• Content-MD5: represents a digest of the transport object. The file server should indicate the MD5 hash value 
whenever multiple versions of the file are anticipated for the download session. 

NOTE 2: The values for each of the above data elements are calculated or discovered by the FLUTE sender. 

The FEC-OTI-Scheme-Specific-Info FDT Instance data element contains information specific to the FEC scheme 
indicated by the FEC Encoding ID encoded using base64. 
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7.2.10 FDT Schema 

7.2.1 0.1 Extended FLUTE FDT Schema 

The below XML Schema shall be use for the FDT Instance. 

The XML schema described in clause 7.2.10.3 is within this schema reference using the relative URI "ietf-flute- 
fdt.xsd". 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns="urn : IETF : metadata : 2005 : FLUTE : FDT" 
xmlns : f l="urn : IETF : metadata : 2005 : FLUTE : FDT" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 
xmlns : mbms = " urn : 3GPP : metadata : 2 5 : MBMS : FLUTE : FDT" 
targetNamespace= " urn : IETF : metadata : 2 5 : FLUTE : FDT" 
elementFormDefault=" qualified" > 

<xs : import namespace= "urn : 3GPP : metadata : 2005 :MBMS : FLUTE : FDT"/ > 
<xs : redefine schemaLocation="ietf -flute- fdt .xsd" > 
<xs : complexType name="FileType" > 
<xs : complexContent> 

<xs : extension base="f 1 : FileType" > 
<xs : sequence> 

<xs:element name="Group" type="mbms igroupIdType" minOccurs="0" 

maxOccur s = " unbounded " / > 
<xs : element name="MBMS-Session-Identity" 

type="mbms : MBMS -Session- Identity- Type" minOccurs=" 0" 
maxOccur s = " unbounded " / > 
</xs : sequence> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType > 

<xs : complexType name="FDT-InstanceType" > 
<xs : complexContent> 

<xs : extension base="f 1 : FDT-InstanceType" > 
<xs : sequence> 

<xs:element name="Group" type="mbms igroupIdType" minOccurs=" 0" 

maxOccur s = " unbounded " / > 
<xs : element name="MBMS-Session-Identity-Expiry" 

type="mbms : MBMS -Session- Identity- Expiry- Type" minOccurs="0" 
maxOccur s= " unbounded" / > 
</xs : sequence > 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : redef ine> 
</xs : schema> 



7.2.1 0.2 3GPP FDT Extension Type Schema 

The extension of the IETF FLUTE FDT schema is done using the following schema definition: 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns = " urn : 3GPP : metadata : 2 5 : MBMS : FLUTE : FDT" 
xmlns :xs="http: //www.w3 .org/2 01/XMLSchema" 
targetNamespace= " urn : 3GPP : metadata : 2 5 : MBMS : FLUTE : FDT" 
elementFormDefault=" qualified" > 

<xs : complexType name="MBMS-Session-Identity-Expiry-Type" > 
<xs : simpleContent> 

<xs : extension base="MBMS-Session-Identity-Type" > 

<xs : attribute name="value" type="xs lunsignedlnt" use="required"/> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType > 
<xs : simpleType name="MBMS-Session-Identity-Type" > 

<xs : restriction base="xs :unsignedByte"/> 
</xs : simpleType> 
<xs : simpleType name="groupIdType" > 

<xs : restriction base="xs : string" ></xs : restriction> 
</xs : simpleType> 
</xs : schema> 
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7.2.10.3 IETF FDT Schema 

Below is the XML schema that has been used to vaUdate the above XML schema extension. 

Note: As the schema in RFC 3926 is not vaHd there exist no stable reference, thus this specification will include this 
schema until IETF has published an updated version of the schema. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns = " urn : I ETF : metadata : 2 5 : FLUTE : FDT " 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 
targetNamespace= " urn : IETF : metadata : 2 5 : FLUTE : FDT" 
elementFormDefault=" qualified" > 

<xs:element name="FDT-Instance" type="FDT-InstanceType"/> 
<xs : complexType name="FDT-InstanceType" > 
<xs : sequence> 

<xs:element name="File" type="FileType" maxOccurs=" unbounded" /> 

<xs : any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name=" Expires" type="xs : string" use="required"/> 
<xs : attribute name=" Complete" type="xs : boolean" use="optional"/> 
<xs : attribute name="Content-Type" type="xs : string" use="optional"/> 
<xs : attribute name="Content-Encoding" type="xs : string" use="optional"/> 
<xs : attribute name="FEC-OTI-FEC-Encoding-ID" type="xs :unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI-FEC-Instance-ID" type="xs :unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI -Maximum- Source -Block- Length" type="xs lunsignedLong" 

use= "optional "/> 
<xs : attribute name ="FEC-OTI- Encoding- Symbol -Length" type="xs lunsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI -Max-Number- of -Encoding- Symbols" type="xs lunsignedLong" 

use= " optional " / > 
<xs : attribute name="FEC-OTI-Scheme-Specif ic-Info" type="xs :base64Binary" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
<xs : complexType name="FileType" > 
<xs : sequence> 

<xs : any namespace="##other" processContents="skip" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="Content-Location" type="xs : anyURI" use=" required" /> 
<xs : attribute name="TOI" type="xs :positiveInteger" use="required"/> 
<xs : attribute name="Content-Length" type="xs :unsignedLong" use="optional"/> 
<xs : attribute name= "Transfer-Length" type="xs :unsignedLong" use="optional"/> 
<xs : attribute name="Content-Type" type="xs : string" use="optional"/> 
<xs : attribute name="Content-Encoding" type="xs : string" use="optional"/> 
<xs : attribute name=" Content -MD5" type="xs :base64Binary" use="optional"/> 
<xs : attribute name="FEC-OTI-FEC-Encoding-ID" type="xs lunsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI-FEC-Instance-ID" type="xs : unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI -Maximum- Source -Block- Length" type="xs : unsignedLong" 

use= "optional "/> 
<xs : attribute name="FEC-OTI- Encoding- Symbol -Length" type="xs : unsignedLong" use="optional"/> 
<xs : attribute name="FEC-OTI -Max-Number- of -Encoding- Symbols" type="xs : unsignedLong" 

use= " optional " / > 
<xs : attribute name="FEC-OTI-Scheme-Specif ic-Info" type="xs :base64Binary" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType > 
</xs : schema> 



7.2.10.4 Example of FDT 



<?xml version="l . 0" encoding="UTF-8" ?> 
<FDT-Instance 

xmlns="urn : IETF : metadata : 2005 : FLUTE : FDT" 

xmlns :xsi="http : //www. w3 .org/2 01/XMLSchema- instance" 

xsi : schemaLocation="urn: IETF imetadata: 2005 : FLUTE : FDT 3gpp-f lute-f dt-choice3 .xsd" 

FEC-OTI -FEC- Encoding- 10= " 1 " 

Complete= " true " 

Content - Encoding= " gz ip " 

FEC-OTI -Encoding- Symbol -Length=" 5 12" 

Expires=" 331129600 "> 

<File 

Cont ent- Type ="applicat ion/ sdp" 
Content -Length=" 754 3" 
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Transfer-Length="42 94" 

T0I="2" 

FEC-OTI -Encoding- Symbol -Length=" 16" 

FEC-OTI- Scheme- Specif ic-Info="AAEBBA==" 

Content -Location="http : //www. example . com/fancy- session/main. sdp" > 

<MBMS-Session-Identity>93</MBMS-Session-Identity> 
</File> 
<File 

Content -Type=" String" 

Content -Length=" IS 1934" 

Transfer-Length="15 7821" 

T0I="3" 

FEC-OTI -Encoding- Symbol -Length=" 512" 

Content -Location="http : //www. example . com/f ancy- session/ trailer . 3gp" > 

<MBMS- Session- Identity>93</MBMS- Session- Identity> 
</File> 

<MBMS- Session- Identity- Expiry value= " 331128876 " >93</MBMS-Session-Identity-Expiry> 
</FDT-Instance> 

7.2.10.5 3GPP FDT Extensions 

The following schema defines the new elements 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns= "urn : 3GPP : metadata : 2007 : MBMS : FLUTE : FDT" 

xmlns :xs="http: //www.w3 . org/2 1/XMLSchema" 

targetNamespace= " urn : 3GPP : metadata : 2 7 : MBMS : FLUTE : FDT" 

elementFormDefault=" qualified" > 

<xs : element name=" Cache- Control "> 
<xs : complexType> 
<xs :choice> 

<xs:element name="no-cache" type="xs iboolean" f ixed="true"/> 
<xs:element name="max-stale" type="xs iboolean" f ixed="true"/> 
<xs:element name= "Expires" type="xs :unsignedInt"/> 

</xs :choice> 

<xs lanyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element> 

</xs : schema> 



7.2.1 1 MBMS Session Identify 



The MBMS-Session-Identity element associates the file to the identity of the MBMS session. If the file will be part of 
several MBMS transmission sessions, then a list of MBMS session identities is defined. 

The MBMS-Session-Identity-Expiry element associates an expiration time with a MBMS session identity value. 
Similar to the FLUTE FDT expiration time, the MBMS session identity expiration time (value attribute) is expressed 
within the FDT Instance payload as a 32 bit data field. The value of the data field represents the 32 most significant 
bits of a 64 bit Network Time Protocol (NTP) [78] time value. These 32 bits provide an unsigned integer representing 
the time in seconds relative to hours 1 January 1900. 

7.2.12 FEC Scheme definition 
7.2.12.1 General 

This clause defines an FEC encoding scheme for the MBMS forward error correction code defined in [91] for the 
download delivery method. This scheme is identified by FEC Encoding ID 1 . The FEC Payload ID format and FEC 
Object Transmission Information format are as defined in [91], sub-clauses 3.1 and 3.2 respectively. 

7.2.13 Caching Directives 

A file download service may indicate the caching recommendations for a specific file or set of files that are delivered 
using FLUTE. The caching directives are to be used with the file download modes as follows: 
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• Promiscuous mode: it is recommended to use the caching directives with the promiscuous mode as it enables 
improved management of the storage at the UE. AppHcations make use of available copies of files as long as 
their respective caching time is still valid. In case one or several files have expired and the download session is 
still available, the UE should join the FLUTE session and download the expired files. Alternatively, the UE may 
attempt to retrieve the file using HTTP and the file URL. 



• 



• 



One-Copy mode: Caching directives may be used with the one-copy mode to indicate the validity of a certain 
file. Applications requesting the file will receive the cached file as long as it is still valid. A file that is not 
expected to be static may indicate a long expiry time or permanent validity. 

Keep-Updated mode: it is recommended to use the caching directives with the keep-updated mode to indicate the 
vaUdity of a certain file. Applications requesting the file will receive the cached file as long as it is still valid. 



The caching functionality defines three different caching directives: 

• no-cache: this directive is used to indicate to the receiver not to cache a specific file (or set of files). This is 
probably useful in the case where the file is expected to be highly dynamic (changes to the file occur quite often) 
or if the file will be used only once by the receiver application. 

• max-stale: this directive indicates to the FLUTE receiver that a specific file (or set of files) should be cached for 
an indefinite period of time, if possible. The file has no expiry date. 

• Expires: this directive is used by the server to indicate the expected expiry time of a specific file (or set of files). 
It indicates a date and time value in the HTTP date format or in the NTP timestamp format. 

The syntax of the caching directives is described in section 7.2.10.5. 

7.2.14 Indicating a full FDT snapshot 

If the server wants to inform the client about the current FDT snapshot, the server shall set the "FullFDT" attribute in 
the FLUTE FDT instance file. If the "FullFDT" attribute is set, the FDT instance shall be equivalent to the full File 
Delivery Table. Note FDT instances with a higher FDT instance ID may again extend the File Delivery Table. 

A new attribute "FullFDT" is created within the element "FDT-Instance" of the FDT to indicate to the receivers that the 
FDT Instance contains the exact set of Transport Objects that are currently scheduled for transmission by the sender, in 
the actual FLUTE session. 

The XML syntax of the "FullFDT" attribute within the FLUTE FDT is the following. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn: 3GPP imetadata : 2008 :MBMS : FLUTE : FDT_ext " 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP imetadata : 2008 iMBMS : FLUTE : FDT_ext " 

elementFormDefault=" qualified" > 

<attribute name=" FullFDT" type= "boolean" 
use="optional" def ault="f alse" /> 
</schema> 

This attribute differs from the existing "Complete" attribute in that the "Complete" attribute indicates that no new 
objects description will be provided in future FDT Instances within this session. 

No assumption shall be made about the fact that a given FDT instance for which the attribute "FullFDT" is absent or set 
to FALSE, contains the exact set of Transport Objects that are currently scheduled for transmission by the sender, in the 
actual FLUTE session. 

When two FDT instances with attribute "FullFDT" is equal to TRUE are received by a receiver and valid in a given 
time (that is to say they have not expired), the FDT instance with the highest FDT Instance ID shall be used by the 
terminal. 

7.2.15 Decryption key indicating of protected download data 

A MBMS download service may indicate relevant decryption key file for protected download file in FLUTE FDT 
instance. A new attribute "Decryption-KEY-URI" is created within element "file" of the FDT to indicate the 
association between protected download file and relevant decryption key file. The value of "Decryption-KEY-URI" in 
"file" element shall be equal to the content-location of the MIKEY file that contains the decryption key file. 
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When the server dehvers a protected download file, the server should set a "Decryption-KEY-URI" field in the 
corresponding file element in the FLUTE FDT instance. When a UE receives a protected file, the UE may instruct its 
FLUTE receiver to download the relevant decryption key file according to "Decryption-KEY-URI" field in file element 
of FDT instance. 

The XML syntax of the "Decryption-KEY-URI" attribute within the FLUTE FDT is the following. 

<?xml version="LO" encoding="UTF-8"?> 
<xs:schemaxmlns="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext" 

xmlns:xs="http://www.w3.org/2001/XMLSchema" 

targetNamespace="urn:3GPP:metadata:2009:MBMS:FLUTE:FDT_ext" 

elementFormDefault="qualified"> 

<attribute name="Decryption-KEY-URI" type="xs:anyURr' use="optionar'/> 
</schema> 

7.3 SDP for Download Delivery Method 

7.3.1 Introduction 

RFC 3926 [9] describes required and optional parameters for FLUTE session and media descriptors. This clause 
specifies SDP for FLUTE session that is used for the MBMS download and service announcement sessions. The formal 
specification of the parameters is given in ABNF ([23]). 

7.3.2 SDP Parameters for MBMS download session 

The semantics of a Session Description of an MBMS download session includes the following parameters: 

The sender IP address. 

The number of channels in the session. 

The destination IP address and port number for each channel in the session per media. 

The Transport Session Identifier (TSI) of the session. 

The start time and end time of the session. 

The protocol ID (i.e. FLUTE/UDP). 

Media type(s) and fmt-hst. 

Data rate using existing SDP bandwidth modifiers. 

Mode of MBMS bearer per media. 

EEC capabilities and related parameters. 

Service-language(s) per media. 
This Ust includes the parameters required by FLUTE - RFC 3926 [9] 
These shall be expressed in SDP ( [14] and [15]) syntax according to the following clauses. 

7.3.2.1 Sender IP address 

There shall be exactly one IP sender address per MBMS download session, and thus there shall be exactly one IP source 
address per complete MBMS download session SDP description. The IP source address shall be defined according to 
the source-filter attribute ("a=source-filter:") ( [14] and [15]) for both IPv4 and IPv6 sources, with the following 
exceptions: 

1 . Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and 
inclusive-mode shall use exactly one source address in the <src-list>. 
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2. There shall be exactly one source-filter attribute per complete MBMS download session SDP description, and 
this shall be in the session part of the session description (i.e. not per media). 

3. The * value shall be used for the <dest-address> sub field, even when the MBMS download session employs only 
a single LCT (multicast) channel. 

7.3.2.2 Number of channels 

Only one FLUTE channel is allowed per FLUTE session in the present document and thus there is no further need for a 
descriptor of the number of channels. 

7.3.2.3 Destination IP address and port number for channels 

The FLUTE channel shall be described by the media-level channel descriptor. These channel parameters shall be per 
channel: 

• IP destination address. 

• Destination port number. 

The IP destination address shall be defined according to the "connection data" field ("c=") of SDP ( [14]). The 
destination port number shall be defined according to the <port> sub-field of the media announcement field ("m=") of 
SDP ([14]). 

The presence of a FLUTE session on a certain channel shall be indicated by using the "m-line" in the SDP description 
as shown in the following example: 

m=application 12345 FLUTE/UDP 

c=IN IP6 FF1E:03AD::7F2E:172A:1E24/1 

In the above SDP attributes, the m-line indicates the media used and the c-line indicates the corresponding channel. 
Thus, in the above example, the m-line indicates that the media is transported on a channel that uses FLUTE over UDP. 
Further, the c-line indicates the channel address, which, in this case, is an IPv6 address. 

7.3.2.4 Transport Session Identifier (TSI) of the session 

The combination of the TSI and the IP source address identifies the FLUTE session. Each TSI shall uniquely identify a 
FLUTE session for a given IP source address during the time that the session is active, and also for a large time before 
and after the active session time (this is also an LCT requirement - RFC 3451 [11]). 

The TSI shall be defined according the SDP descriptor given below. There shall be exactly one occurrence of this 
descriptor in a complete FLUTE SDP session description and it shall appear at session level. 

The syntax in ABNF is given below: 

flute-tsi-line = "a=flute-tsi:" tsi CRLF 

tsi= 1*15DIGIT 

7.3.2.5 Multiple objects transport indication 

RFC 3626 [9] requires the use of the Transport Object Identifier (TOI) header field (with one exception for packets with 
no payload when the A flag is used). The transport of a single FLUTE file requires that multiple TOIs are used (TOI 
for FDT Instances). Thus, there is no further need to indicate to receivers that the session carries packets for more than 
one object and no SDP attribute (or other FLUTE out of band information) is needed for this. 

7.3.2.6 Session Timing Parameters 

A MBMS download session start and end times shall be defined according to the SDP timing field ("t=") ( [14]). 
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7.3.2.7 Mode of MBMS bearer per media 

A new MBMS bearer mode declaration attribute is defined which results in, e.g.: 

• a=mbms-mode:broadcast 1234 1 
OR 

• a=mbms-mode:broadcast-sfn 1234 

The MBMS bearer mode declaration attribute shall be used in session descriptions using one or more MBMS broadcast 
mode media or broadcast-sfn mode media. If all media declarations use MBMS broadcast mode or broadcast-sfn mode, 
then the SDP attribute may be declared at session level. In that case the session level attribute applies to all media 
without a media level occurance of the "mbms-mode" attribute. If one or more media using MBMS multicast mode is 
present in the same declaration as media using MBMS broadcast mode, then only media using the MBMS broadcast 
mode or broadcast-sfn mode will contain the "mbms-mode" attribute. 

mbms-bearer-mode-declaration-line = "a=mbms-mode:" ("broadcast" SP tmgi SP mbms -counting-information) / 
("broadcast-mbsfn" SP tmgi) CRLF 

tmgi= 1*15DIGIT 

mbms -counting-indication = 1 * DIGIT 

The Temporary Mobile Group Identity (tmgi) information element is defined in TS 24.008 [40]. Octets 3 to 8 are 
always encoded in tmgi attribute as a decimal number. Octet 3 is the most significant octet. 

The MBMS Counting Information (mbms-counting-information) information element is defined in TS 25.413 [87] and 
indicates whether the RAN level counting procedures are applicable or not for the MBMS broadcast mode. The value 
corresponds to the information element value of "not counting" and the value 1 corresponds to the information element 
value "counting". 

7.3.2.8 FEC capabilities and related parameters 

A new FEC-declaration attribute is defined which results in, e.g.: 

• a= FEC-declaration: encoding-id=l 

This attribute may be used on both session-level and media-level. Multiple instances are allowed to specify several 
different FEC declarations. The attribute is used on session level to define FEC declarations used by multiple media 
components. On media level it is used to define FEC declarations which are only valid for a single media component. If 
FEC declarations on both session and media level use the same reference number (fec-ref) then the media level 
declaration takes precedence for that media component. Each media component references one FEC declaration using 
the "a=FEC" attribute. 

This attribute is optional to use for the download delivery method as the information will be available elsewhere (e.g. 
FLUTE FDT Instances). If this attribute is not used, and no other FEC-OTI information is signalled to the UE by other 
means, the UE may assume that support for FEC id is sufficient capability to enter the session. 

A new FEC-declaration reference attribute is defined which results in, e.g.: 

• a=FEC:0 

This is a media-level only attribute, used as a short hand to reference one of one or more FEC-declarations. 
The syntax for the attributes in ABNF [23] is: 

fee -declaration-line = "a= FEC-declaration:" fec-ref SP fec-enc-id [";" SP fec-inst-id] CRLF 

fec-ref = 1 *3DIGIT ; value is the SDP-internal identifier for FEC-declaration. 

fec-enc-id = "encoding-id=" enc-id 

enc-id = 1 *DIGIT ; value is the FEC encoding ID used 

fec-inst-id = "instance-id=" inst-id 
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inst-id = 1 *DIGIT ; value is the FEC Instance ID used, 
fee-line = "a=FEC:" fec-ref CRLF 

7.3.2.9 Service-language(s) per media 

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken 
from [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3166 [75] 
(e.g. "a=lang:EN-US"). These are the same tags used in the User Service Description XML. 

7.3.2.10 Bandwidth Specification 

The maximum bit-rate required by this FLUTE session shall be specified using the "AS" bandwidth modifier [14] on 
media level. The Application Specific (AS) bandwidth for a FLUTE session shall be the largest sum of the sizes of all 
packets transmitted during any one second long period of the session, expressed as kilobits. The size of the packet shall 
be the complete packet, i.e. IP, UDP and FLUTE headers, and the data payload. 

7.3.3 SDP Examples for FLUTE Session 

Here is a full example of SDP description describing a FLUTE session: 

v=0 

o=userl23 2890844526 2890842807 IN IP6 2201 : 056D : : 112E : 144A: 1E24 

s=File delivery session example 

i=More information 

t=2873397496 2873404696 

a=mbms -mode : broadcast 1234 1 

a=FEC-declaration: encoding- id=l 

a=source- filter: incl IN IP6 * 2001 -.210 -.1 -.2 -.240 : 96FF:FE25 : 8EC9 

a=flute-tsi : 3 

m=application 12345 FLUTE/UDP 

C=IN IP6 FFIE: 03AD : : 7F2E : 1 72A : 1E24/1 

b=64 

a=lang :EN 

a=FEC:0 

7.4 OMA Push usage for MBMS Download 

7.4.1 Introduction 

OMA Push may be used for MBMS download reception when MBMS Bearers are not available. The MBMS UE 
registers its MSISDN with the BM-SC to receive the Download Sessions using OMA Push. The BM-SC distributes 
FLUTE FDT instance which allows the MBMS UE to fetch files of interest. 

If the MBMS UE is out of its home network and if at least one unicastAccessURI element is available in the deliver 
method description, the MBMS UE should register its MBMS Download Services with the BM-SC. 

7.4.2 HTTP registration and deregistration procedure 

The MBMS UE may register and deregister for unicast service delivery, if the MBMS User Service Description for this 
service includes at least one unicastAccessURI t\&v(\tn\. in the deliveryMethod tl&va&ni. 

The HTTP (RFC 2616 [18]) GET method is used for this purpose. If more than one unicastAccessURI is, provided in the 
deliveryMethod element, the UE shall randomly select one. 

In the following, we give the details of the syntax used for the above request method in ABNF [23]. 

• unicast_access_request_http_URL = unicast_access_URI "?" query 

• unicast_access_URI = <unicastAccessURI from the User Service Description; URI-reference is as defined in 
[19].> 

• query = action "&" serviceld "&" msisdn 
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• action = "action=" ("register" I "Register" I "deregister" I "Deregister") 

• serviceld = "serviceld=" <value of the serviceld attribute of the User Service Description> 

• msisdn = "msisdn=" 1 *DIGIT <format as defined in [77] 

The BM-SC responds with an "200 OK" status code in case of successful registration or deregistration. With the 
response to a successful registration request, an associated delivery procedure fragment as defined in clause 9.5 shall be 
delivered to the MBMS UE. The MBMS UE uses the File Repair procedure as described in the received associated 
delivery procedure description fragment. The file repair procedure is defined in clause 9.3. Note, the file repair 
procedure allows also to fetch complete files. 

An HTTP GET request with "action" value set to "register" or "Register" shall be sent to register the MBMS UE for 
unicast file delivery service. The request shall also include the serviceld and the MSISDN of the MBMS UE. The 
format for the MSISDN is defined in [77]. The following is an exmaple for a registration request: 

GET /unicasDelivery?action=Register&serviceId=urn:3gpp:0010120123hotdog&MSISDN=436642012345 
HTTP/1.1 

Host: bmsc.example.com 

An HTTP GET request with "action" value set to "deregister" or "Deregister" shall be sent to deregister the MBMS 
UE from the unicast file delivery service. The request also includes the service ID and the MSISDN number of the 
MBMS UE as shown in the following example: 

GET /unicasDelivery?action=Deregister&serviceId=urn: 3gpp:00 1 1 20 1 23hotdog&MSISDN=4366420 1 2345 
HTTP/1.1 

Host: bmsc.example.com 

7.4.3 MBMS Download Delivery Method over OMA push bearers 

MBMS Download over OMA Push bearers are formatted according to the OMA Push OTA specification [79]. 

OTA-WSP shall be used over unicast bearers. Application port addressing shall be used as specified in [79]. The 
appHcation ID to be used is 0x9045 as allocated by OMNA [85]. 

OTA-HTTP may be used over the HTTP push bearer. Application port addressing shall be used as specified in [79]. 
The application ID to be used is 0x9045 as allocated by OMNA [85]. 

The Content-Encoding header shall be included if GZip is used. 

The MBMS UE receives the FLUTE FDT instance and the Download Header instance via OMA Push OTA protocol 
[79]. Both documents are encapsulated in a multipart MIME document. Optionally an associated delivery description 
fragment as defined in clause 9.5 is part of the pushed document. The FLUTE FDT instance is identified by the MIME 
type "application/fdt+xml" and the associated delivery description fragment by the mimetype as defined in Annex C.7. 
The download header instance should use a default mime type "application/xml". 

The XML schema for the download header fragment is defined below. The serviceld element contains the unique 
identifier of the MBMS service. The MBMS UE uses the Service Id to select the target application and has received the 
serviceld with the User Service Annoucement fragment. The format of the serviceld element is defined in clasue 
n.2.LL 

The fdtlnstanceld element shall contain the FDT instance Identifier for the sent FDT instance. Note, the FDT instance 
id is transferred using the FDT Instance Header as defined in clause 3.4.1 of [9] 

<?xml version="1.0" encoding="UTF-8"?> 

<xs:schemaxmlns="urn:3GPP:metadata:2007:MBMS:downloadHeader" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" 

targetNamespace="urn urn:3GPP:metadata:2007:MBMS:downloadHeader" 
elementFormDefault="qualified" attributeFormDefault="unqualified"> 

<xs:element name="mbmsDownloadHeader"> 
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<xs:complexType> 
<xs:sequence> 

<xs:element name="serviceld" type="xs:anyURI" use="required"/> 
<xs:element name="fdtlnstanceld" type="xs:unsignedlnt" use="required"/> 
<xs:any namespace="##other" processContents="lax" minOccurs="0"/> 
</xs:sequence> 
</xs : complexType> 
</xs:element> 
</xs:schema> 



The UE will then have necessary information about all files in the FLUTE session including their fileURIs, content 
encodings, content lengths etc. 

7.5 FLUTE session setup and control with RTSP 

7.5.1 Introduction 

In case the MBMS User Service contains MBMS Streaming and MBMS Download delivery sessions, it may be 
beneficial to control all flows with RTSP. The prime use case of FLUTE session set-up and control with RTSP is for 
sending MBMS streaming associated presentation data. 

7.5.2 SDP handling 

The FLUTE specific SDP extensions are defined in clause 7. For the FLUTE session establishment using RTSP, a 
control URI as defined in [88] shall be present for the FLUTE media description. Note, a control URI is defined by the 
"a=control:" SDP field according to [88]. 

7.5.3 RTSP SETUP IVIethod 

The control URI as defined in [88] shall be present for each FLUTE media description in the SDP. The control URI is 
used within the RTSP SETUP method to establish the described FLUTE sessions. 

The RTSP transport protocol specifier for FLUTE as defined in [88] shall be "FLUTE/UDP". One and only one UDP 
port is allocated for each FLUTE channel. 

The following RTP specific parameters shall be used in the transport request and responds header for FLUTE sessions: 

• client_port: This parameter provides the unicast FLUTE port(s) on which the client has chosen to receive 
FLUTE data. 

• server_port: This parameter provides the unicast FLUTE port(s) on which the server has chosen to send data. 

7.5.4 RTSP PLAY IVIethod 

The PLAY method tells the server to start sending data including FLUTE session data as defined in [88]. The RTSP 
server forwards the FLUTE packets as according by the RTSP range header in the RTSP PLAY. 

Only ntp and clock range units may be used with the "Range" headers. Normal Play Time (NPT) indicates the stream 
absolute position relative to the beginning of the presentation. The NPT consists of a decimal fraction.The clock range 
header describe the absolute time expressed as ISO 8601 timestamps, using UTC (GMT). 
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7.5.5 RTSP PAUSE Method 

The PAUSE request causes the stream deUvery including all FLUTE sessions to be interrupted (halted) as defined in 
[88]. 

7.5.6 RTSP TEARDOWN Method 

The TEARDOWN client to server request stops the stream delivery including all FLUTE data delivery for the given 
URI, freeing the resources associated with it. Details for the TEARDOWN method are defined in [88]. 



8 Streaming delivery method 

8.1 Introduction 

The purpose of the MBMS streaming delivery method is to deliver continuous multimedia data (i.e. speech, audio, 
video and DIMS) over an MBMS bearer. Using MBMS Streaming delivery on unicast is defined in clause 8.5. This 
delivery method complements the download delivery method which consists of the delivery of files. The streaming 
delivery method is particularly useful for multicast and broadcast of scheduled streaming content. 



8.2 Transport protocol 



RTP is the transport protocol for MBMS streaming delivery. RTF provides means for sending real-time or streaming 
data over UDP and is already used for the transport of PSS in 3GPP. RTP provides RTCP for feedback about the 
transmission quality. The transmission of RTCP packets in the downlink (sender reports) is allowed. In this version of 
the specification, RTCP RR shall be turned off by SDP RR bandwidth modifiers. Note that in the context of MBMS 
detection of link aliveness is not necessary. 

8.2.1 RTP pay load formats for media 

The RTP payload formats and corresponding MIME types are closely aligned with those defined in PSS [47] . For 
RTP/UDP/IP transport of continuous media the following RTP payload formats shall be used: 

• AMR narrow-band speech codec (see sub-clause 10.2) RTP payload format according to RFC 4867 [33]. A 
MBMS client is not required to support multi-channel sessions. 



• 



AMR wideband speech codec (see sub-clause 10.2) RTP payload format according to RFC 4867 [33]. A MBMS 
client is not required to support multi-channel sessions. 

Extended AMR-WB codec (see sub-clause 10.3) RTP payload format according to [34]. 

Enhanced aacPlus codec (see sub-clause 10.3) RTP payload format and MIME types according to RFC 3640 
[41], namely the Low Bit-Rate AAC or the High Bit-Rate AAC modes. 
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• H.264 (AVC) video codec (see sub-clause 10.5) RTP payload format according to RFC 3984 [35]. An MBMS 
client supporting H.264 (AVC) is required to support all three packetization modes: single NAL unit mode, non- 
interleaved mode and interleaved mode. For the interleaved packetization mode, an MBMS client shall support 
streams for which the value of the "sprop-deint-buf-req" MIME parameter is less than or equal to MaxCPB * 
1000 / 8, inclusive, in which "MaxCPB" is the value for Video Coding Layer (VCL) parameters of the H.264 
(AVC) profile and level in use, as specified in [43]. 

• DIMS (see sub-clause 10.12) RTP payload format according to [89]. 

• Timed Text (see sub-clause 10.10) RTP payload format according to [93]. 

8.2.2 FEC mechanism for RTP 

The "MBMS FEC scheme" is described in sub-clause 8.2.2.8. 

A UE that supports MBMS User Services shall support a decoder for the "MBMS FEC scheme". The use of MBMS 
FEC by the sender is recommended, but it is permitted not to use it. In the case where the FEC is not used by the sender, 
the FEC Layer should not be used (i.e. RTP is mapped onto UDP directly). 

This sub-clause defines a generic mechanism for applying Forward Error Correction to streaming media. The 
mechanism consists of three components: 

(i) construction of an FEC source block from the source media packets belonging to one or several UDP packet 
flows related to a particular segment of the stream(s) (in time). The UDP flows include RTP, RTCP, SRTP and 
MIKEY packets. 

(ii) modification of source packets to indicate the position of the source data from the source packet within the 
source block 

(iii)defmition of repair packets, sent over UDP, which can be used by the FEC decoder to reconstruct missing 
portions of the source block. 

The mechanism does not place any restrictions on the source data which can be protected together, except that the 
source data is carried over UDP. The data may be from several different UDP flows that are protected jointly. 

A receiver supporting the streaming delivery method shall support the packet format for FEC source packets and may 
also support the packet format for FEC repair packets. 

At the sender, the mechanism begins by processing original UDP packets to create: 

(i) a stored copy of the original packets in the form of a source block; and 

(ii) FEC source packets for transmission to the receiver. 

After constructing the source block from the original UDP payloads to be protected and their flow identity (based on 
destination IP address and UDP port), the FEC encoder generates the desired amount of FEC protection data, i.e. 
encoding symbols. These repair symbols are then sent using the FEC repair packet format to the receiver. The FEC 
repair packets are sent to a UDP destination port different from any of the original UDP packets' destination port(s) as 
indicated by the signaling. 

The receiver recovers the original packets directly from the FEC source packets and buffers them at least min-buffer- 
time to allow time for the FEC repair. The receiver uses the FEC source packets to construct a (potentially incomplete) 
copy of the source block, using the Source FEC Payload ID in each packet to determine where in the source block the 
packet shall be placed. The indication of the UDP flow (i.e. destination IP address and UDP port number) that the 
packet is part of, is included in the source block with the UDP payload. 

If any FEC source packets have been lost, but sufficient FEC source and FEC repair packets have been received, FEC 
decoding can be performed to recover the FEC source block. The original packets UDP payload and UDP flow identity 
can then be extracted from the source block and provided to the upper layer. If not enough FEC source and repair 
packets were received, only the original packets that were received as FEC source packets will be available. The rest of 
the original packets are lost. 
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If a UE that supports MBMS User Services receives a mathematically sufficient set of encoding symbols generated 
according to the encoder specification in Annex B for reconstruction of a source block, then the decoder shall recover 
the entire source block. Note that the example decoder described in [91] clause 5.5 fulfils this requirement. 

Note that the receiver must be able to buffer all the original packets and allow time for the FEC repair packets to arrive 
and FEC decoding to be performed before media playout begins. The min-buffer-time parameter specified in sub-clause 
8.3.1.8 helps the receiver to determine a sufficient duration for initial start-up delay. 

The Source and Repair FEC payload IDs are used to associate the FEC source packets and FEC repair packets, 
respectively, to a source block. The Source and Repair FEC payload ID formats are part of the definition of the FEC 
scheme. Each FEC scheme is identified by an FEC Encoding ID and, in the case of underspecified FEC schemes, FEC 
Instance ID, values. One FEC scheme for the streaming delivery method is specified in sub-clause 8.2.2.8. Any FEC 
schemes using the packet formats defined in the present document shall be systematic FEC codes and may use different 
FEC payload ID formats for FEC source packets and FEC repair packets. 

The protocol architecture is illustrated in figure 1 1 . 
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Figure 1 1 : FEC mechanism for thie streaming delivery method interaction diagram 



Figure 1 1 depicts how one or more out of several possible packet flows of different types (Audio, video, DIMS, text 
RTP and RTCP flows, MIKEY flow) are sent to the FEC layer for protection. The source packets are modified to carry 
the FEC payload ID and a new flow with repair data is generated. The receiver takes the source and repair packets and 
buffers them to perform, if necessary, the FEC decoding. After appropriate buffering received and recovered source 
packets are forwarded to the higher layers. The arrows in the figure indicate distinct data flows. 



8.2.2.1 



Sending Terminal Operation (Informative) 



It is assumed that the sender has constructed or received original data packets for the session. These may be RTP, 
RTCP, MIKEY or other UDP packets. The following procedures are based on the UDP payload and the identity of the 
UDP flow. 
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In order to FEC protect a sequence of original data packets, the sender constructs a source block as specified in sub- 
clause 8.2.2.6 to which the FEC algorithm is to be applied, and includes the original source packet data within FEC 
source packets. The following operations describe a possible way to generate compliant FEC source packet and FEC 
repair packet streams: 

1. Each original packet is placed in the source block. In doing so, the Source FEC Payload ID information to be 
included in the FEC payload ID of the FEC source packet can be determined. In the source block the identity of 
the packet's flow is marked using the Flow ID. See sub-clauses 8.2.2.6 and 8.2.2.7 for details. 

2. The FEC source packet is constructed according to sub-clause 8.2.2.4. The identity of the original flow is 
maintained by the source packet through the use of the destination UDP port number and destination IP address, 
which has been advertised (for example using SDP), as carrying FEC source packets generated from an original 
stream of a particular protocol (e.g. RTP, RTCP, SRTP, MIKEY etc.). See sub-clause 8.2.2.13. 

3. The generated FEC source packet is sent using UDP. 

When a source block is complete, the FEC encoder generates encoding symbols and places these symbols into FEC 
repair packets, to be conveyed to the receivers. These repair packets are sent using normal UDP procedures to a unique 
destination port to separate it from any of the source packet flows. 

In particular cases it may be advantageous not to use FEC for some source blocks and to signal this to the receiver. In 
this case the sender may send one or more empty repair packets consisting exclusively of the Repair FEC Payload ID. 
This will be helpful in particular for selective FEC where some of the source blocks (e.g. consisting of reference video 
frames) are FEC protected while others (e.g. consisting exclusively of non-reference frames) will not be protected. 

8.2.2.2 Receiving Terminal Operation (Informative) 

The following describes a possible receiver algorithm, when receiving an FEC source or repair packet: 

1. If a FEC source packet is received (as indicated by the UDP port on which was received): 

a. The original source packet is reconstructed by removing the Source FEC Payload ID. The resulting packet is 
buffered to allow time for the FEC repair. 

b. The resulting packet is placed into the source block according to the information in the Source FEC Payload 
ID and the source block format described in sub-clause 8.2.2.6. The UDP port the packet was received on is 
used to determine the Flow ID written into the source block. 

2. If an FEC repair packet is received (as indicated by the UDP port), the contained encoding symbols are placed 
into an FEC encoding block according to the Repair FEC Payload ID. In case the received FEC repair packet is 
empty, there are no repair symbols to be placed in the FEC encoding block. 

3. If at least one source packet is missing, then FEC decoding may be desirable. The FEC decoder determines if 
the encoding block constructed in steps 1 and 2 contains enough symbols from the source and repair packets for 
decoding and, if so, performs the decoding operation. If only empty FEC repair packets are received, the receiver 
may start immediately some procedures to conceal the effect of missing media data. 

4. Any missing source packets that were reconstructed during the decoding operation are then buffered as normal 
received packets (see step la above). 

Note that the above procedure may result in that not all original packets are recovered, and they must simply be marked 
as being lost. 

Obviously, buffering and packet re-ordering are required to insert any reconstructed packets in the appropriate place in 
the packet sequence if that is necessary according to the used higher layer protocol (RTP, RTCP or MIKEY). To allow 
receivers to determine the minimal start-up buffering requirement for FEC decoding, the min-buffer-time parameter 
indicates a minimum initial buffering time that is sufficient regardless of the position of the stream in which the 
reception starts. 

8.2.2.3 (Void) 



£75/ 



3GPP TS 26.346 version 9.1.0 Release 9 



52 



ETSI TS 126 346 V9.1.0 (2010-01) 



8.2.2.4 



Packet format for FEC source packets 



The packet format for FEC source packets shall be used to encapsulate an original UDP packet.. As depicted in figure 
12, it consists of the original UDP packet, followed by the Source FEC payload ID. 



IP Header 



UDP Header 



Original UDP Payload 



Source FEC Payload ID 



Figure 12: Structure of the FEC packet format for FEC source packets 

The destination IP address and UDP port shall be set as indicated in the session control signalling. This ensures that the 
receiver can determine which protocols and FEC Payload ID formats are used for this flow. The remaining fields in the 
IP and UDP headers shall be set according to their specifications. 

The UDP payload shall consist of the original UDP Payload followed by the Source FEC Payload ID. 

The Source FEC Payload ID consists of information required for the operation of the FEC algorithm. Its construction 
is specified in sub-clause 8.2.2.9. 

The FEC Source packets over IP and UDP are indicated to be used for a flow by using one of the SDP protocol 
identifiers "UDP/MBMS-FEC/RTP/AVP", "UDP/MBMS-FEC/RTP/SAVP" depending on the upper layer protocol 
RTP/AVP or RTP/S AVP respectively. If MIKEY is FEC protected and encapsulated in source packets, then it is 
indicated in the security description using the fecProtection element and the destination IP address. 



8.2.2.5 



Packet Format for Repair packets 



The packet format for FEC repair packets carries, as its payload, encoding symbols generated by the FEC encoding 
process. The format of a FEC repair packet is depicted in figure 13. The UDP payload consists of the Repair FEC 
Payload ID, and zero, one or more repair symbols. The format of the Repair FEC payload ID is defined in clause 
8.2.2.10. 
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IP Header 



UDP Header 



Repair FEC Payload ID 



Repair symbols 



Figure 13: Payload structure for FEC repair packets 

The repair packet sent over IP and UDP is indicated in the SDP using the protocol identifier "UDP/MBMS-REPAIR". 

8.2.2.6 Structure of the FEC source block 

This clause defines the layout of the FEC source block. 

The FEC source block shall contain at least one complete UDP packet payload (i.e. excluding the IP and UDP headers), 
and three octets indicating the UDP flow from which the packet was taken and the length of the UDP packet. Note: 
this implies that no source UDP packet be larger than the length of the FEC source block minus 3. 

Let 

n be the number of UDP packets in the source block, n is determined dynamically during the source block 
construction process. 

Rj denote the octets of the UDP payload of the fth UDP packet to be added to the source block. 

Z, be the length of /?, in octets. 

L, denote two octets representing the value of Z, in network byte order (high order octet first). 

/ denote an integer "flow ID" identifying the UDP flow from which the i* packet was taken 

Fj denote a single octet representing the value of/ 

si be the smallest integer such that sfT >= (li+3). 

Pj denote SiT-( Z,+3) zero octets. Note: P, are padding octets to align the start of each UDP packet with the start of a 
symbol. 

T be the source symbol size in bytes. 

Then, the source block is constructed by concatenating Fj ,Li, Rj, Pj for / = 1, 2, ... n. and the source block size, S = 
sum [SjT, i=l, ..., n). 

A UDP flow is uniquely defined by an IP source and destination address and UDP source and destination port value. 
The assignment of Flow ID values to UDP flows is described in sub-clauses 8.2.2.13 and 8.3.1.9. 



8.2.2.7 



FEC block Construction algorithm and example (informative) 



When the original UDP packet is placed into the source block, the value of the UDP flow identifier, F, followed by the 
value of the UDP payload length, L, are first written as a single byte and two-byte value in network byte order (i.e. with 
high order byte first) respectively into the first available bytes in the source block, followed by the UDP packet payload 
itself (i.e. not including the IP/UDP headers). Following this, if the next available byte is not the first byte of a new 
symbol, then padding bytes up to the next symbol boundary shall be included using the value in each byte. As long as 
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any source UDP packets remain to be placed, the procedure is repeated starting each UDP flow identifier at the start of 
the next encoding symbol. 

An example of forming a source block is given in figure 14 below. In this example, three UDP packets of lengths 26, 52 
and 103 bytes have been placed into a source block with symbol size T = 16 bytes. The first two packets are from UDP 
flow and the third from UDP flow 1. Each entry in Figure 14 is a byte and the rows correspond to the source symbols 
and are numbered from to 12. Bij denotes the (j+l)th byte of the (i+l)th UDP packet. 
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Figure 14: Source block consisting of 3 source UDP packets of lengths 26, 52 and 103 bytes. 



8.2.2.8 



MBMS FEC scheme definition 



This clause defines a FEC encoding scheme for MBMS forward error correction as defined in Annex B for the 
streaming delivery method. This scheme is identified by the FEC encoding ID 1. It utilizes the method for forming FEC 
source block as defined in sub-clause 8.2.2.6. It defines two different FEC Payload ID formats, one for FEC source 
packets and another for FEC repair packets. 

8.2.2.9 Source FEC Payload ID 

The Source FEC payload ID is composed as follows: 



Source Block Number (SBN) 



Encoding Symbol ID (ESI) 



Source Block Number (SBN), (16 bits): An integer identifier for the source block that the source data within the 

packet relates to. 
Encoding Symbol ID (ESI), (16 bits): The starting symbol index of the source packet in the source block. 



Figure 15: Source FEC Payload ID 
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The interpretation of the Source Block Number and Encoding Symbol Identifier is defined in Annex B. 

8.2.2.10 Repair FEC payload ID 

The structure of the Repair FEC Payload ID is as follows: 



Source Block Number (SBN) 



Encoding Symbol ID (ESI) 



Source Block Length (SBL) 



Source Block Number (SBN), (16 bits): An integer identifier for the source block that the repair symbols within the 

packet relate to. 

Encoding Symbol ID (ESI), (16 bits): An integer identifier for the encoding symbols within the packet. 

Source Block Length (SBL), (16 bits): The number of source symbols in the source block. 

The interpretation of the Source Block Number, Encoding Symbol Identifier and Source Block Length is defined in 

Annex B. 

Figure 16: Repair FEC Payload ID 

In case of empty Repair FEC packets, the actual value of ESI is irrelevant and it may take any value between 0X0000 
and OXFFFF. 

8.2.2.10a FEC Object Transmission information 

The FEC Object Transmission information shall consist of: 

the maximum source block length, in symbols 

the symbol size, in bytes 

The symbol size and maximum source block length shall be encoded into a 4 octet field (Network Byte Order) defined 
as follows: 



Symbol Size (7) 


Maximum Source Block Length 



Symbol Size (T) (16 bits): The size of an encoding symbol, in bytes. 

Maximum Source Block Length (16 bits): The maximum length of a source block, in symbols. 

The interpretation of T is defined in Annex B. 

The Source Block Length signalled within the Repair FEC Payload ID of any packet of a stream shall not exceed the 
Maximum Source Block Length signalled within the FEC Object Transmission Information for the stream. 

The FEC Object Transmission Information shall be communicated as described in sub-clause 8.2.2.14. Note, the FEC 
Object Transmission Information is only communicated in SDP. 

8.2.2.1 1 Hypothetical FEC Decoder 

This clause specifies the hypothetical FEC decoder and its use to check packet stream and MBMS receiver 
conformance. 

The hypothetical FEC decoder uses the packet stream, the transmission time of each packet, the initial buffering delay, 
and the SDP for the stream as inputs. The packet stream from the beginning of the FEC source block until the end of the 
stream shall comply with the hypothetical reference decoder as specified below when the initial buffer delay equals to 
the value of the min-buffer-time parameter. 



£75/ 



3GPP TS 26.346 version 9.1 .0 Release 9 56 ETSI TS 1 26 346 V9.1 .0 (201 0-01 ) 

The maximum hypothetical FEC decoding buffer size for MBMS streaming is 1 Mbytes. The default hypothetical FEC 
decoding buffer size is equal to 1 Mbytes. 

For the packet stream, the buffer occupancy level of the hypothetical FEC decoding buffer shall not exceed the value of 
the buf-size parameter, when it is present in the SDP, or the default FEC decoding buffer size, when the buf-size 
parameter is not present in the SDP. The output of the hypothetical FEC decoder shall comply with the RTF payload 
and decoding specifications of the media format. 

The hypothetical FEC decoder operates as follows: 

1) The hypothetical FEC decoding buffer is initially empty. 

2) Each FEC source packet and FEC repair packet, starting from the first packet in transmission order, is inserted 
into a FEC source block at its transmission time. The FEC source block generation is done as specified in sub- 
clause 8.2.2.7. The FEC source block resides in the hypothetical FEC decoding buffer. 

3) When both the last FEC source packet and the last FEC repair packet of an FEC source block are transmitted, 
any elements of the FEC source block that are not original UDP packets (e.g. FEC repair packets and potential 
padding bytes) are removed from the hypothetical FEC decoding buffer. 

4) Original UDP packets are not removed from the hypothetical FEC decoding buffer before the signaled initial 
buffering delay has expired. Then, the first original UDP packet in sequence number order is output and removed 
from the hypothetical FEC decoding buffer immediately. Each succeeding original UDP packet is output and 
removed when the following conditions are true: 

i. The following time (in seconds) since the removal of the previous packet has elapsed: 

8 X (size of the previous original UDP packet including UDP/IP header in bytes) / (1 000 x (value of 
"b=AS" SDP attribute for the stream)) 

ii. All the packets in the same FEC source block as the original UDP packet have been transmitted. 

An MBMS client shall be capable of receiving a packet stream that complies with the hypothetical FEC decoder. 
Furthermore, in the case of RTP packets, when an MBMS client complies with the requirements for the media decoding 
of the packet stream, it shall be able to de-packetize and decode the packet stream and output decoded data at the 
correct rate specified by the RTP timestamps of the received packet stream. 

8.2.2.12 FEC encoding procedures 

EEC encoding shall be performed using the MBMS forward error correction code defined in Annex B. 

8.2.2.13 Signalling 

The signalling for streaming FEC consists of several components: 

• If several user services are bundled together they are indicated as a sequence of services in the User Service 
Bundle Description. See sub-clause 1 1 .2. 

• A separate SDP describing the FEC repair stream and all the flow IDs referenced from the User Service 
Bundle Description. See sub-clauses 11.2 and 8.2.2.14. 

• SDP protocol identifiers and attributes to indicate the usage of the source packet format, how the FEC payload 
ID is configured and other FEC parameters such as minimal buffering delay, for the RTP/RTCP streams. See 
sub-clause 8.2.2.13a. 

• Security description extensions to indicate usage of FEC source packet format, and the FEC parameters. See 
sub-clauses 11.3 and 8.2.2.13a. 

The user service description contains either a single service or several bundled services. All of the streaming delivery 
methods and security descriptions that are present within the bundleDescription element must be considered when 
configuring the FEC operations. This includes RTP, RTCP and MIKEY flows. A receiver intending to perform FEC 
decoding to cover for packet losses shall receive all the flows that are indicated to be sent as FEC source packets, even 
if the flows are in a service currently not played out. A receiver intending to use FEC shall also receive the FEC repair 
stream as described by the FEC Repair Stream Description. The delivery method's session description, and the security 
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description both carry the FEC source packet configuration information: FEC encoding ID, EEC instance ID, and EEC 
OTI information. The EEC repair packet stream is configured using the similar methods as for the source packets, with 
the addition of the Elow ID information and buffer delay parameter. 

8.2.2.1 3a SDP for FEC source packet streams 

To indicate the presence of the EEC layer between IP/UDP and, RTP or SRTP a SDP protocol identifier is used. Instead 
of the normal RTP/AVP and RTP/SAVP protocol identifiers, 'UDP/MBMS-EEC/RTP/AVP' and 'UDP/MBMS- 
EEC/RTP/SAVP' are defined respectively. Both these protocol identifiers shall use the EMT space rules that are used 
for RTP/AVP and RTP/SAVP respectively, i.e. payload types used in the RTP session is listed. The protocol identifiers 
are defined in Appendix C 1 . 

The EEC parameters, EEC encoding ID, EEC instance ID and EEC-OTI-Extension information are signalled using the 
mechanism defined in sub-clause 8.3.1.8. The "a=EEC" SDP attribute shall be used to indicate the single definition that 
is used for each media component. 

Eor MIKEY messages the service protection description is used to indicate when EEC source packet shall be used, see 
sub-clause 11.3. The EEC parameter used is also defined in the service protection description. As all MIKEY packets 
from all user services arrive on the same port, the receiver must use the destination address to separate EEC protected 
packets from not EEC protected packets. This requires that all MIKEY packets sent to a specific destination address are 
either EEC protected or not. Note that it is not possible to mix protected and non-protected packets within a single 
stream as there is no mechanism to determine whether they are protected or not. 

8.2.2.14 SDP for FEC repair packet streams 

The repair packet stream is indicated in SDP using a media block with the protocol identifier "UDP/MBMS-REPAIR". 
The media type shall be "application". The EEC parameters, EEC encoding ID, EEC instance ID, EEC-OTI-Extension 
information and repair parameters (min-buffer-time) are signalled using the mechanisms defined in sub-clause 8.3.1.9. 
Each media component shall reference only one EEC declaration. 

The mapping of the EEC source block flow ID (see sub-clause 8.2.2.6) to the destination IP address and UDP port are 
done using the SDP attribute "a=mbms-flowid" defined in sub-clause 8.3.1.9. 

Interleaving may be signaled using the "X-3gpp-EEC-Interleaving" attribute, which also gives the arrangement of the 
flows in the source block and by consequence their transmission order. The "X-3gpp-EEC-Interleaving" attribute is 
defined in sub-clause 8.3.1.11. 

8.2.2.15 Signalling example for FEC 

This sub-clause contains a complete signalling example for a MBMS multicast mode session using EEC with a Service 
description, a SDP for the streaming delivery method, a SDP for the EEC repair stream, and a security description. 

The following is an example bundleDescription. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns="urn: 3GPP : metadata : 2005 :MBMS lUserServiceDescription" 

xmlns :xsi=" http : //www. w3 . org/2 01/XMLSchema- instance " 

f ecDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl-f ec . sdp" > 

<userServiceDescription 

serviceld="urn: 3gpp: 01012 0123hotdog" > 
<deliveryMethod 

sessionDescriptionURI=" http : //www. example . com/3gpp/mbms/sessionl . sdp " 
protectionDescriptionURI="http : //www. example . com/3gpp/mbms/sec-descript"/> 
</userServiceDescription> 
</bundleDescription> 

The security description has the URJ: http://www.example.com/3gpp/mbms/sec-descript 

<?xml version="l . 0" encoding="UTF-8" ?> 
<securityDescription 

xmlns="urn: 3GPP : metadata : 2005 :MBMS : securityDescription" 

xmlns :xsi="http : //www. w3 .org/2 01/XMLSchema- instance" 

conf identialityProtection="true" 

integrityProtect ion= " true " 

uiccKeyManagement = " true " 
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< keyManagement 
waitTime="5" 
maxBackOff="10"> 

<serverURI>http : //register. example . com/</serverURI> 
<serverURI>http : //register2 . example . com/</serverURI> 
< / keyManagement > 
<keyld> 

<mediaFlow f lowID="FFlE : 03AD : : 7F2E : 172A: 1E24/4002 " > 
<MSK> 

<keyDomainID>aMoM</keyDomainID> 
<MSKID>aMoAAA==</MSKID> 
</MSK> 
</mediaFlow> 

<mediaFlow f lowID="FFlE : 03AD : : 7F2E : 172A: 1E24/4004 " srtpAuthenticationTagLength="4 " > 
<MSK> 

<keyDomainID>GM8M</keyDomainID> 
<MSKID>aMkAAA==</MSKID> 
</iyiSK> 
</mediaFlow> 
</keyId> 
<fec Protect ion 

f ecEncodingId= " 1 " 
fecOtiExtension="ACAEAA=="/> 
</securityDescription> 

An example of how the SDP http://www.example.com/3gpp/mbms/sessionl.sdp could look for a session containing two 
media streams that are FEC protected. In this example we have assumed an audiovisual stream, using 56 kbps for video 
and 12 kbps for audio. In addition another 300 bits/second of RTCP packets from the source is used for the each of the 
sessions. Hence, the total media session bandwidth is 56+12+0.3+0.3 = 68.6 kbps. 

v=0 

o=ghost 2890844526 2890842807 IN IP6 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

s=3GPP MBMS Streaming SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. infoserver . example . com/ae6 

e=ghost®mailserver . example . com 

C=IN IP6 FFIE: 03AD: :7F2E:172A:1E24 

t=3034423619 3042462419 

b=AS:62 

b=TIAS: 6 0500 

a=maxprate: 25 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

a=FEC- declaration: encoding- id=l 

m=video 4002 UDP/MBMS-FEC/RTP/AVP 96 

b=TIAS: 55000 

b=RR: 

b=RS:300 

a=rtpmap:96 H263-2000/90000 

a=fmtp:96 prof ile=3 ; level=10 

a=framesize: 96 176-144 

a=FEC:0 

a=maxprate : 15 

m=audio 4004 UDP/MBMS-FEC/RTP/AVP 98 

b=TIAS: 11500 

b=RR: 

b=RS:300 

a=rtpmap:98 AMR/8000 

a=fmtp:98 octet-align=l 

a=FEC: 

a=maxprate : 10 

The FEC stream used to protect the above RTP sessions and a MIKEY key stream has the below SDP 
(http://www.example.com/3gpp/mbms/sessionl-fec.sdp): 

v=0 

o=ghost 2890844526 2890842807 IN IP6 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

s=3GPP MBMS Streaming FEC SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. infoserver. example . com/ae6 

e=ghost@mailserver . example . com 

C=IN IP6 FF1E:03AD: :7F2E:172A:1E24 

t=3034423619 3042462419 

b=AS:15 

a=FEC-declaration: encoding-id=l 

a=FEC-OTI-extension: ACAEAA== 
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a=mbms -repair: min-buf f er-time=2600 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

m=application 4006 UDP/MBMS-REPAIR * 

b=AS:15 

a=FEC: 

a=mbms-flowid: 1=FF1E:03AD: : 7F2E : 172A: 1E24/4002 , 2=FF1E:03AD: : 7F2E : 172A: 1E24/4003 , 

3=FF1E:03AD: : 7F2E : 172A : 1E24/4004 , 4=FF1E:03AD: : 7F2E : 172A : 1E24/40 05 , 5=FF1E:03AD: : 7F2E : 172A : 1E24/2269 

a=X-3gpp-FEC-Interleaving: l="reverse", 2="ordered" 

A more traditional FEC configuration is shown below. The audio and video media components use different FEC repair 
flows. The same principle can also be applied when bundling several user services together. 

<?xml version="l . 0" encoding="UTF-8"?> 
<bundleDescription 

xmlns="urn: 3GPP : metadata : 2005 :MBMS lUserServiceDescription" 

xmlns :xsi=" http : //www. w3 . org/2 01/XMLSchema- instance " 

f ecDescriptionURI="http : //www. example . com/3gpp/mbms/session2-f ec . sdp" > 

<userServiceDescription 

serviceld="urn: 3gpp : 01012 0123hotdog" > 
<deliveryMethod 

sessionDescriptionURI=" http : //www. example . com/3gpp/mbms/session2 . sdp "/> 
</userServiceDescription> 
</bundleDescription> 

The SDP file from above is modified to use two different FEC flows. 

v=0 

o=ghost 2890844526 2890842807 IN IP6 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

s=3GPP MBMS Streaming SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. infoserver . example . com/ae6 

e=ghost@mailserver . example . com 

C=IN IP6 FF1E:03AD: :7F2E:172A:1E24 

t=3034423619 3042462419 

b=AS:62 

b=TIAS: 605 00 

a=maxprate: 25 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

m=video 4002 UDP/MBMS-FEC/RTP/AVP 96 

b=TIAS: 55000 

b=RR:0 

b=RS:300 

a=FEC-declaration: encoding-id=l 

a=rtpmap:96 H263-2000/90000 

a=fmtp:96 prof ile=3 ; level=10 

a=framesize: 96 176-144 

a=FEC:0 

a=maxprate : 15 

m=audio 4004 UDP/MBMS-FEC/RTP/AVP 98 

b=TIAS: 11500 

b=RR: 

b=RS:300 

a=FEC- declaration: 1 encoding- id=l 

a=rtpmap:98 AMR/8000 

a=fmtp:98 octet-align=l 

a=FEC:l 

a=maxprate : 10 

The SDP file for the two FEC streams 

v=0 

o=ghost 2890844526 2890842807 IN IP6 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

s=3GPP MBMS Streaming FEC SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. infoserver. example . com/ae6 

e=ghost®mailserver . example . com 

t=3034423619 3042462419 

b=AS:15 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

m=application 4006 UDP/MBMS-REPAIR * 

C=IN IP6 FF1E:03AD: :7F2E:172A:1E24 

b=AS:15 
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a=FEC-declaration: encoding- id=l 

a=FEC-OTI-extension:0 ACAEAA== 

a=mbms -repair: min-buf f er-time=2600 

a=FEC: 

a=I1lbms-flowid: 1 = FF1E:03AD: : 7F2E : 172A: 1E24/4002 , 2=FF1E:03AD: : 7F2E : 172A : 1E24/4003 

m=application 4008 UDP/MBMS-REPAIR * 

C=IN IPS FFIE: 03AD: :7F2E:172A:1E24 

b=AS:15 

a=FEC- declaration: 1 encoding- id=l 

a=FEC-OTI-extension:l ACAEAA== 

a=mbms -repair: 1 min-buf fer-time=2600 

a=FEC:l 

a=mbms-flowid: 3=FF1E:03AD: : 7F2E : 172A: 1E24/4004 , 4=FF1E:03AD: : 7F2E : 172A: 1E24/4005 



8.2.3 General RTP Header Extension Mechanism 

8.2.3.1 Introduction 

The General RTP Header Extension Mechanism [92] is a general mechanism to use the header extension feature of RTP 
(the Real-Time Transport Protocol). The General RTP Header Extension Mechanism should be supported. 

8.2.3.2 Timestamp Offset 

Timestamp offsets for RTP may be transmitted using the general RTP header extension mechanism. 

The variable timestamp extension element is 32 bits long. The first byte is the extension element header, i.e. the ID 
and len fields, as defined in [92]. The remaining 3 bytes are the timestamp-offset measured in the same frequency as 
the RTP timestamp. 

Timestamp-offset: A 24 bit unsigned integer signaling the offset of the received packets of the same media in the tune- 
in EEC block. The timestamp offset indicates at most the difference between the RTP timestamp of the current packet 
and the highest RTP timestamp of packets of the same media stream that are transmitted in the current FEC source 
block. 

Timestamp offset shall not be used if FEC protection and Interleaving are not being used. 

The following example is a general RTP header extension block containing a single variable timestamp extension 
element. 

12 3 

01234567890123456789012345678901 

I OxBEDE I length=l | 

I ID I len=2 | timestamp-offset | 

The presence of variable timestamps is signaled in the SDP file using the header extension specification and the URI 
"http://www.3gpp.org/2008/TimestampOffset". The URI signals the possible presence of timestamp offsets with the 
given ID. 



8.3 Session description 



SDP is provided to the MB MS client via a discovery/announcement procedure to describe the streaming delivery 
session. The SDP describes one or more RTP sessions part of the MBMS streaming session. The SDP shall be a 
correctly formed SDP according to [14]. 

8.3.1 SDP Parameters for IVIBIVIS streaming session 

The semantics of a Session Description of an MBMS streaming session shall include the parameters: 



£75/ 



3GPP TS 26.346 version 9.1 .0 Release 9 61 ETSI TS 1 26 346 V9.1 .0 (201 0-01 ) 

The sender IP address. 

The number of media in the session. 

The destination IP address and port number for each and all of the RTP sessions in the MBMS streaming 
session. 

The start time and end time of the session. 

The protocol ID (i.e. RTP/AVP). 

Media type(s) and fmt-list. 

Data rate using existing SDP bandwidth modifiers. 

Mode of MBMS bearer per media. 

FEC configuration and related parameters. 

Service-language(s) per media. 

QoE Metrics (defined in sub-clauses 8.3.2.1 and 8.4). 

8.3.1.1 Sender IP address 

There shall be exactly one IP source address per media description within the SDP. The IP source address shall be 
defined according to the source-filter attribute ("a=source-filter:") [15] for both IPv4 and IPv6 sources, with the 
following exceptions: 

1. Exactly one source address may be specified by this attribute such that exclusive-mode shall not be used and 
inclusive-mode shall use exactly one source address in the <src-list>. 

2. There shall be exactly one source-filter attribute per complete MBMS streaming session SDP description, and 
this shall be in the session part of the session description (i.e. not per media). 

3. The * value shall be used for the <dest-address> subfield. 

8.3.1 .2 Destination IP address and port number for channels 

Each RTP session part of a MBMS streaming session is defined by two parameters: 

• IP destination address. 

• Destination port number(s). 

The IP destination address shall be defined according to the "connection data" field ("c=") of [14]. The destination port 
number shall be defined according to the <port> sub-field of the media announcement field ("m=") of [14]. Multiple 
ports using "/" notation shall not be used. The RTCP port, if used, shall be RTP port +1. 

8.3.1.3 Media Description 

The media description line shall be used as defined in [14] for RTP. The <media> part indicates the type of media, 
audio, video, or text. The usage of RTP and any applicable RTP profile shall be indicated by using the <proto> field of 
the 'm-line'. The one or more payload types that are being used in this RTP session are enumerated in the <fmt> part. 
Each payload type is declared using the "a=rtpmap" attribute according to [14] and use the "a=fmtp" line when required 
to describe the payload format parameters. 

8.3.1 .4 Session Timing Parameters 

A MBMS streaming session start and end times shall be defined according to the SDP timing field ("t=") - [14]. 
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8.3.1 .5 Mode of MBMS bearer per media 

The MBMS bearer mode declaration attribute shall be used for MBMS streaming sessions, as defined in sub-clause 
7.3.2.7. 

8.3.1 .6 Service-language(s) per media 

The existing SDP attribute "a=lang" is used to label the language of any language-specific media. The values are taken 
from [73] which in turn takes language and (optionally) country tags from ISO 639 [74] and ISO 3166 [75] (e.g. 
"a=lang:EN-US"). These are the same tags used in the User Service Description XML. 

8.3.1.7 Bandwidth specification 

The bit-rate required by the MBMS streaming session and its media components shall be specified using both the "AS" 
bandwidth modifier and the "TIAS" bandwidth modifier combined with "a=maxprate" [38] on media level in the SDP. 
On session level the "TIAS" bandwidth modifier combined with "a=maxprate" may be used, where the session level 
expresses the aggregated peak bit-rate, which may be lower than the sum of the individual media streams. 

The bandwidth required for RTCP is specified by the "RR" and "RS" bandwidth modifiers (3GPP TS 26.244 [32]) on 
media level for each RTP session. The "RR" modifier shall be included and set to to specify that RTCP receiver 
reports are not used. The bandwidth used for RTCP sender reports shall be specified using the "RS" bandwidth 
modifier. 

8.3.1.8 FEC Parameters 

The FEC encoding ID and instance ID are provided using the "a=FEC-declaration" attribute defined in sub-clause 
7.3.2.8. Any OTI information for that FEC encoding ID and instance ID is provided with below defined FEC OTI 
attribute. 

The FEC OTI attribute must be immediately preceded by the "a=FEC-declaration" attribute (and so can be session-level 
and media-level). The fec-ref maps the oti-extension to the EEC-declaration OTI it extends. The purpose of the oti- 
extension is to define FEC code specific OTI required for RTP receiver FEC payload configuration; exact contents are 
FEC code specific and need to be specified by each FEC code using this attribute. The OTI for the MBMS FEC Scheme 
is defined in sub-clause 8.2.2.10a. 

The syntax for the attributes in ABNF [23] is: 

• sdp-fec-oti-extension-line = "a=FEC-OTI-extension:" fec-ref SP oti-extension CRLF 

• fec-ref = 1*3DIGIT (the SDP-internal identifier for the associated EEC-declaration). 

• oti-extension = base64 

• base64 = *base64-unit [base64-pad] 

• base64-unit = 4base64-char 

• base64-pad = 2base64-char "==" / 3base64-char "=" 

• base64-char = ALPHA / DIGIT / "H-" / "/" 

To provide the FEC repair packets with additional, non FEC specific parameters, a session and media level SDP 
attribute is defined. 

sdp-fec-parameter-line = "a=mbms-repair: 0*1SP fec-ref SP parameter-list CRLF 

parameter-list = parameter-spec *(1*SP parameter-spec) 

parameter-spec = name "=" value; 

name = 1 *(ALPHA / DIGIT / "-") 

value = l*(safe) ; safe defined in [14] 
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Currently one FEC non code-specific parameter is defined: 

mill-buffer- time: Tiiis FEC buffering parameter specifies tlie minimum receiver buffer time (delay) needed to ensure 
that FEC repair has time to happen regardless of the FEC source block of the stream from which the reception 
starts. The value is in milliseconds and represents the wallclock time between the reception of the first FEC 
source or repair packet of a FEC source block, whichever is earlier in transmission order, and the wallclock time 
when media decoding can safely start. 

The parameters name and value is defined in ABNF as follows: 

Min-buffer-time-parameter-name = "min-buffer-time" 

Min-buffer-time-parameter-value = 1*8DIGIT ; Wallclock time in milliseconds. 

The FEC declaration and FEC OTI information utilized in a specific source or repair packet is indicated using the FEC- 
ref number in the a=fec lines as described in sub-clauses 8.2.2.12 and 8.2.2.13. 

8.3.1 .9 FEC Flow ID attribute 

To indicate the mapping between destination IP address and UDP port number and FEC source block flow IDs, the 
"a=mbms-flowid" SDP attribute is defined. Each flowID that is used to construct a source block within the bundled 
sessions shall be included. It is a media level attribute that shall be present in any SDP media block using the 
"UDP/MBMS -REPAIR" protocol identifier. 

The syntax for the attributes in ABNF [23] is: 

Sdp-mbms-flowid-attr = "a=mbms-flowid:" *WSP flow-id-spec *("," *WSP flow-id-spec) CRLF 

flow-id-spec = flowID "=" address-spec "/" port-spec 

address-spec = IP4-multicast / IP6-multicast 

IP4-multicast = ml 3*( "." decimal-uchar ) 

ml = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) / ("23" DIGIT )) 

IP6-multicast = hexpart 

hexpart = hexseq / hexseq "::" [ hexseq ] / 

"::" [hexseq] 

hexseq = hex4 *( ":" hex4) 

hex4 = 1*4HEXDIG 

port-spec = 1*5DIGIT 

8.3.1 .10 Buffer Requirement Signaling 

Due to the variable bitrate nature of some media streams (especially video streams), initial buffering at the receiver 
becomes necessary to smooth out those variations. The initial buffering delay SHOULD be signaled to the receiver in 
the SDP using the following media level attribute: 

• "a=X-initpredecbufperiod:<initial pre-decoder buffering period>" 

For H.263 video streams, the "X-initpredecbufperiod" indicates the required initial pre-decoder buffering period 
specified according to Annex G of 3GPP TS 26.234 [47]. 

For H.264 video streams, the "X-initpredecbufperiod" indicates the nominal removal time of the first access unit from 
the coded picture buffer (CPB). 

Note that X-initpredecbufperiod is expressed as clock ticks of a 90-kHz clock. Hence, conversion may be required if the 
RTP timestamp clock frequency is not 90 kHz. 
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8.3.1.11 Interleaving Signaling 

When interleaving is used in combination with FEC protection of an MBMS service, the BM-SC may indicate to 
receivers the order of transmission of the media units of a source block using the "X-3gpp-FEC -Interleaving" attribute. 
It also indicates whether intra-stream interleaving (described in section G.l) has been performed or not for each of the 
flows in the FEC source block. 

The "X-3gpp-FEC-Interleaving" attribute is defined as follows: 

Interleaving="X-3gpp-FEC-Interleaving:" SP flow_interleaving *("/' flow_interleaving) CRLF 

flow_interleaving=flowID "=" ["ordered" / "mixed" / "reverse"] 

flowID is the indentification of the flow as described in section 8.3.1.9. The intra-stream interleaving modes may result 
in un-changed tranmission order ("Ordered"), a mixed transmission order ("Mixed"), or a reversed transmission order 
("Reverse"). For a flow that is not listed in the X-3gpp-FEC-Interleaving attribute, the receiver should assume that no 
particular intra- or inter-stream interleaving has been performed. The transmission order does not preculde that some 
media units of a lower priority stream are interleaved with the media units of higher priority stream. 

8.3.2 SDP Example for Streaming Session 

Here is a full example of SDP description describing the media streams part of a streaming delivery session: 

v=0 

o=ghost 2890844526 2890842807 IN IP4 192.168.10.10 

s=3GPP MBMS Streaming SDP Example 

i=Example of MBMS streaming SDP file 

u=http : //www. infoserver . example . com/ae6 

e=ghost@mailserver . example . com 

C=IN IP6 FFIE: 03AD : : 7F2E : 1 72A :1E24 

t=3034423619 3042462419 

b=AS:77 

a=mbms -mode : broadcast 1234 1 

a=source-filter: incl IN IP6 * 2001 : 210 : 1 : 2 : 240 : 96FF : FE25 : 8EC9 

m=video 4 02 RTP/AVP 96 

b=TIAS: 62000 

b=RR:0 

b=RS:600 

a=maxprate : 17 

a=rtpmap:96 H264/90000 

a=fmtp : 96 prof ile- level -id=42A0 IE; packet i zat ion-mode= 1 ; sprop-parameter-sets=ZOIACpZTBYmI , aMlj iA= = 

m=audio 4004 RTP/AVP 98 

b=TIAS: 15120 

b=RR: 

b=RS:600 

a=maxprate : 10 

a=rtpmap:98 AMR/8000 

a=fmtp:98 octet-align=l 

FEC is not used in that example. See clause 8.2.2.15 for an example with FEC. 



8.3.2.1 SDP Description for QoE Metrics 

Similar as in 3GPP TS 26.234 [47], an SDP attribute for QoE, which can be used either at session or media level, is 
defined below in [23] based on [14]: 

• QoE-Metrics-Une = "a" "=" "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF 

• att-measure-spec = Metrics ";" Sending-rate [";" Measure -Range] 

[";" Measure-Resolution] *([";" Parameter-Ext]) 

• Metrics = "metrics" "=" "{"Metrics-Name *("l" Metrics-Name) " }" 

• Metrics-Name = I*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}" 

• Sending-Rate = "rate" "=" 1*DIGIT / "End" 
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• Measure-Resolution = "resolution" "=" 1 *DIGIT ; in seconds 

• Measure-Range = "range" ";" Ranges-Specifier 

• Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (I*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e)) 

• Ranges-Specifier = as defined in RFC 2326 [88]. 

An MBMS server uses this attribute to indicate that QoE metrics are supported and shall be used if also supported by 
the MBMS client. When present at session level, it shall only contain metrics that apply to the complete session. When 
present at media level, it shall only contain metrics that are applicable to individual media. 

The "Metrics" field contains the list of names that describes the metrics/measurements that are required to be reported in 
a MBMS session (see sub-clause 8.4). The names that are not included in the "Metrics" field shall not be reported 
during the session. 

In this version of the specification, the "Sending-Rate" shall be set to the value "End", which indicates that only one 
report is sent at the end of the MBMS session. 

The optional "Measure-Resolution" field, if used, shall define a time over which each metrics value is calculated. The 
"Measure-Resolution" field splits the session duration into a number of equally sized periods where each period is of the 
length specified by the "Measure-Resolution" field. The "Measure-Resolution" field is thus defining the time before the 
calculation of a QoE parameter starts over. If the "Measure -Resolution" field is not present the metrics resolution shall 
cover the period specified by the "Measure-Range" field. If the "Measure-Range" field is not present the metrics 
resolution shall be the whole session duration. 

The "Measure-Resolution" field shall take only one value for all session level metrics and only one value for all metrics 
associated to one media. Note that "Measure-Resolution" shall be evaluated according to a real-time clock. This implies 
that the real-time interval between consecutive measurements is not affected by changes in playback rate, for instance 
due to buffering. 

The optional "Measure-Range" field, if used, shall define the time range in the stream for which the QoE metrics will be 
reported. There shall be only one range per measurement specification. The range format shall be any of the formats 
allowed by the media. If the "Measure-Range" field is not present, the corresponding (media or session level) range 
attribute in SDP shall be used. If SDP information is not present, the metrics range shall be the whole session duration. 

8.3.2.2 OMA-DM Configuration of QoE Metrics 

As an alternative to configure the QoE reporting for each session (as specified in 8.3.2.1), OMA-DM can be used to 
specify the default QoE configuration. If such a default QoE configuration has been specified, it should be used by the 
terminal for all subsequent MBMS sessions where no session-specific QoE configuration is received. 

Any session-specific QoE configuration received shall always have higher priority, and will in such cases override any 
default OMA-DM QoE configuration for that session. 

For OMA-DM QoE configuration the parameters are specified according to the following Managed Object (MO). 
Version numbering is included for possible extension of the MO. 

The Management Object Identifier shall be: urn:oma:mo:ext-3gpp-mbmsqoe:1.0. 

Protocol compatibility: The MO is compatible with OMA Device Management protocol specifications, version 1 .2 
and upwards, and is defined using the OMA DM Device Description Framework as described in the Enabler Release 
Definition OMA-ERELD _DM-V1_2 [94]. 

The following nodes and leaf objects shall be contained under the 3GPP_MBMSQOE node if an MBMS client supports 
the feature described in this clause (information of DDF for this MO is given in Annex H): 



£75/ 



3GPP TS 26.346 version 9.1.0 Release 9 



66 



ETSI TS 126 346 V9.1.0 (2010-01) 



<X>* 



► Enabled 



APN? 



Format? 



Rules 



Session? 



Speech? 



Video? 



Text? 



Ext? 



Metrics? 



Ext? 



► Metrics? 



Ext? 



► Metrics? 



Ext? 



Metrics? 



Ext? 



Node: /<X> 

This interior node specifies the unique object id of a MBMS QoE metrics management object. The purpose of this 
interior node is to group together the parameters of a single object. 

Occurrence: ZeroOrOne 

- Format: node 

- Minimum Access Types: Get 

The following interior nodes shall be contained if the MBMS cUent supports the "MBMS QoE metrics Management 
Object". 

/<X>/Enabled 

This leaf indicates if QoE reporting is requested by the provider. 
Occurrence: One 
Format: bool 
Minimum Access Types: Get 

/<X>/APN 

This leaf contains the Access Point Name that should be used for establishing the PDP context on which the QoE metric 
reports will be transmitted. This may be used to ensure that no costs are charged for QoE metrics reporting. If this leaf 
is not defined then any QoE reporting is done over the access point according to sub-clause 11. 2. 1.1. 
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Occurrence: ZeroOrOne 
Format: chr 

Minimum Access Types: Get 
Values: the Access Point Name 

/<X>/Format 

This leaf specifies the format of the report and if compression (Gzip XML) [xx] is used. 

Occurrence: ZeroOrOne 

Format: chr 

Minimum Access Types: Get 
- Values: "XML", "GZIPXML". 

/<X>/Rules 

This leaf provides in XML format the rules used to decide if and how the reports are sent to the QoE metrics report 
server. The leaf also provides the URIs of one or more servers which shall be the receiver of the QoE metrics report. In 
case of multiple servers, the MBMS client randomly selects one of the servers from the list, with uniform distribution. 

The XML scheme is described in sub-clause 9.5.1 and an example XML code is shown in sub-clause 9.5.2. Only the 
postReceptionReport part needs to be specified. Note that the reportType shall always be set to StaR. 

Occurrence: One 

Format: chr 

Minimum Access Types: Get 

Values: See clause 16.3.3. 

/<X>/Ext 

The Ext node is an interior node where the vendor specific information can be placed (vendor includes application 
vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The 
tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub- 
trees. 

Occurrence: ZeroOrOne 

Format: node 

Minimum Access Types: Get 

/<X>/Session 

The Session node is the starting point of the session level QoE metrics definitions. 
Occurrence: ZeroOrOne 
Format: node 
Minimum Access Types: Get 

/<X>/Sessioii/Metrics 

This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting 
interval and the reporting range. The syntax and semantics of this leaf are defined in clause 8.3.2.1. 

Occurrence: ZeroOrOne 
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Format: chr 

Minimum Access Types: Get 

Values: see clause 8.3.2.1. 

/<X>/Session/Ext 

The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application 
vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The 
tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub- 
trees. 

Occurrence: ZeroOrOne 

Format: node 

Minimum Access Types: Get 

/<X>/Speech 

The Speech node is the starting point of the speech/audio media level QoE metrics definitions. 
Occurrence: ZeroOrOne 
Format: node 
Minimum Access Types: Get 

/<X>/Speech/Metrics 

This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting 
interval and the reporting range. The syntax and semantics of this leaf are defined in clause 8.3.2. 1 . 

Occurrence: ZeroOrOne 

Format: chr 

Minimum Access Types: Get 

Values: see clause 8.3.2.1. 



/<X>/Speech/Ext 



The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application 
vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The 
tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub- 
trees. 

Occurrence: ZeroOrOne 

Format: node 

Minimum Access Types: Get 

/<X>/Video 

The Video node is the starting point of the video media level QoE metrics definitions. 
Occurrence: ZeroOrOne 
Format: node 
Minimum Access Types: Get 

/<X>/Video/Metrics 
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This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting 
interval and the reporting range. The syntax and semantics of this leaf are defined in clause 8.3.2.1. 

Occurrence: ZeroOrOne 

Format: chr 

Access Types: Get 

Values: see clause 8.3.2.1. 

/<X>/Video/Ext 

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, 
device vendor etc.). Usually the vendor extension is identified by vendor specific name under the Ext node. The tree 
structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees. 

Occurrence: ZeroOrOne 

Format: node 

Minimum Access Types: Get 

/<X>/Text 

The Text node is the starting point of the timed-text media level QoE metrics definitions. 
Occurrence: ZeroOrOne 
Format: node 

Minimum Access Types: Get 
Values: see clause 8.3.2.1. 

/<X>/Text/Metrics 

This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting 
interval and the reporting range. The syntax and semantics of this leaf are defined in clause 8.3.2.1. 

Occurrence: ZeroOrOne 

Format: chr 

Minimum Access Types: Get 

Values: see clause 8.3.2.1. 

/<X>/Text/Ext 

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, 
device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree 
structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees. 

Occurrence: ZeroOrOne 

Format: node 

- Minimum Access Types: Get 
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8.4 Quality of Experience 

8.4.1 General 

The MBMS Quality of Experience (QoE) metrics feature is optional for both MBMS streaming server and MBMS 
client, and shall not disturb the MBMS service. An MBMS Server that supports the QoE metrics feature shall activate 
the gathering of client QoE metrics with SDP as described in sub-clauses 8.3.2.1 and 8.4.2 and via the reception 
reporting procedure as described in sub-clause 9.4. Alternatively QoE activation can be done with OMA-DM as 
described in sub-clause 8.3.2.2. An MBMS client supporting the feature shall perform the quality measurements in 
accordance to the measurement definitions, aggregate them into client QoE metrics and report the metrics to the 
specified server using the content reception reporting procedure. The way the QoE metrics are processed and made 
available is out of the scope of the present document. 

8.4.2 QoE IVIetrics 

An MBMS client should measure the metrics at the transport layer after EEC decoding (if EEC is used), but may also do 
it at the application layer for better accuracy. 

The measurement period for the metrics is the whole streaming duration and the measurement resolution of each 
reported metrics value is defined by the "Measure-Resolution" field. The measurement period may be less than the 
session duration, because of late joiners or early leavers. The measurement period shall not include any voluntary event 
that impacts the actual play, such as pause, or any buffering or freezes/gaps caused by them. 

The following metrics shall be derived by the MBMS client implementing QoE. All the metrics defined below are only 
applicable to at least one of audio, video, speech and timed text media types, and are not applicable to other media types 
such as synthetic audio, still images, bitmap graphics, vector graphics, and text. Any unknown metrics shall be ignored 
by the client and not included in any QoE report. Among the QoE metrics, corruption duration, successive loss of RTF 
packets, frame -rate deviation and jitter duration are of media level, whereas initial buffering duration, rebuffering 
duration and content access/switch time are of session level. 

8.4.2.1 Corruption duration metric 

Corruption duration, M, is the time period from the NPT time of the last good frame before the corruption, (since the 
NPT time for the first corrupted frame cannot always be determined) or the start of the measurement period (whichever 
is later)to the NPT time of the first subsequent good frame or the end of the measurement period (whichever is sooner). 
A corrupted frame may either be an entirely lost frame, or a media frame that has quality degradation and the decoded 
frame is not the same as in error-free decoding. A good frame is a "completely received" frame X that, either: 



• 



it is a refresh frame (does not reference any previously decoded frames AND where none of the subsequently 
decoded frames reference any frames decoded prior to X); or 



• does not reference any previously decoded frames; or 

• only references previously decoded "good frames". 

"Completely received" means that all the bits are received and no bit error has occurred. 

Corruption duration, M, in milliseconds can be calculated according to the derivation of good frames as below: 

a) A good frame can be derived by the client using the codec layer, in which case the codec layer signals the 
decoding of a good frame to the client. A good frame could also be derived by error tracking methods, but 
decoding quality evaluation methods shall not be used. An error tracking method may derive that a frame is a 
good frame even when it references previously decoded corrupted frames, as long as all the referenced pixels for 
generating the prediction signal were correctly reconstructed when decoding the reference frames. A decoding 
quality evaluation method may derive that a frame is a good frame even one or more pixels of the frame have not 
been correctly reconstructed, as long as the decoding quality is considered by the method as acceptable. Such a 
frame is not a good frame according to the definition above, which shall be strictly followed. 

b) In the absence of information from the codec layer, a good frame should be derived according to N, where N is 
optionally signalled from MBMS streaming server (via SDP) to the MBMS client and represents the maximum 
duration, in presentation time, between two subsequent refresh frames in milliseconds. After a corrupted frame. 
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if all subsequent frames within N milliseconds in presentation time have been completely received, then the next 
frame is a good frame. 

c) N is not signalled, then it defaults to oo (for video) or to one frame duration (for audio). 

The optional parameter D is defined to indicate which of options a) and b) is in use. D is signalled from the client to the 
server. When D is equal to "a", option a) shall be in use, and the optional parameter T shall be present. When D is equal 
to "b", option b) shall be in use and the optional parameter T shall not be present. 

The optional parameter N as defined in point b is used with the "Corruption_Duration" parameter. The optional 
parameter T is defined to indicate whether the client uses error tracking (when T is equal to "On") or not (when T is 
equal to "Off). T is signalled from the client to the server. 

The syntax for D, N to be included in the "att-measure-spec" (sub-clause 8.3.2.1) is as follows; 

• D = "D" "=" "a" / "b" 

• N="N" "=" 1*DIGIT 

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred corruption 
durations are summed up over each resolution period of the stream and stored in the vector TotalCorruptionDuration. 
The unit of this metrics is expressed in milliseconds. For each resolution duration the number of individual corruption 
events are summed up and stored in the vector NumberOfCorruptionEvents. These two vectors are reported by the 
MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3). 

8.4.2.2 Rebuffering duration metric 

Rebuffering is defined as any stall in playback time due to any involuntary event at the client side. 

The syntax for the metric "Rebuffering_Duration" for the QoE-Feedback header is as defined in sub-clause 8.3.2.1. 

Rebuffering starts at the NPT time of the last played frame before the occurrence of the rebuffering. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the occurred rebuffering 
durations are summed up over each resolution period of the stream and stored in the vector TotalRebujferingDuration. 
The unit of this metrics is expressed in seconds, and can be a fractional value. The number of individual rebuffering 
events for each resolution duration are summed up and stored in the vector NumberOfRebujferingEvents. These two 
vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3). 

8.4.2.3 Initial buffering duration metric 

Initial buffering duration is the time from receiving the first RTP packet until playing starts. 

The syntax for the "Initial_Buffering_Duration" is as defined in sub-clause 8.3.2.1. 

The metric value indicates the initial buffering duration where the unit of this metrics is expressed in seconds, and can 
be a fractional value. There can be only one measure and it can only take one value. "Initial_Buffering_Duration" is a 
session level parameter.This value is reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 
9.5.3). 

8.4.2.4 Successive loss of RTP packets 

The metric "Successive_Loss" indicates the number of RTP packets lost in succession (excluding FEC packets) per 
media channel. 

The syntax for the metrics "Successive_Loss" is as defined in sub-clause 8.3.2.1. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the number of successively lost 
RTP packets are summed up over each resolution period of the stream and stored in the vector 
TotalNumberofSuccessivePacketLoss. The unit of this metric is expressed as an integer equal to or larger than 0. The 
number of individual successive packet loss events over each resolution duration are summed up and stored in the 
vector NumberOfSuccessiveLossEvents. The number of received packets is also summed up over each resolution 
duration and stored in the vector NumberOfReceivedPackets. These three vectors are reported by the MBMS client as 
part of the reception report (sub-clauses 9.4.6 and 9.5.3). 
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8.4.2.5 Frame rate deviation 

Frame rate and frame rate deviation indicates the playback frame rate information. Frame rate deviation happens when 
the actual playback frame rate during a measurement period is deviated from a pre-defmed value. 

The actual playback frame rate is equal to the number of frames played during the resolution period divided by the time 
duration, in seconds, of the actual measurement. For the last measurement period in the session this time duration might 
be shorter than the configured measurement resolution (see 8.3.2.1 for the definition of the measurement resolution). 

The parameter FR that denotes the pre-defined frame rate value is used with the "Framerate_Deviation" parameter in 
the "3GPP-QoE-Metrics" attribute. The value of FR shall be set by the server. The syntax for FR to be included in the 
"att-measure-spec" (sub-clause 8.3.2.1) is as follows: 

• FR = "FR" "=" 1*DIGIT "." 1*DIGIT 

The syntax for the metrics"Framerate" and "Framerate_Deviation" is defined in sub-clause 8.3.2.1 

The metric "Framerate" indicates the actual playback frame rate. It is expressed in frames per second, and can be a 
fractional value.. 

For the Metrics-Name "Framerate_Deviation", the value field indicates the frame rate deviation value that is equal to 
the pre-defmed frame rate minus the actual playback frame rate. This metric is expressed in frames per second, and can 
be a fractional value, and can be negative. 

The frame rate and the frame rate deviations for each resolution period are stored in the vectors Framerate and 
FramerateDeviation and the vectors are reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 
and 9.5.3). 

8.4.2.6 Jitter duration 

Jitter happens when the absolute difference between the actual playback time and the expected playback time is larger 
than a pre-defmed value, which is 100 milliseconds. The expected time of a frame is equal to the actual playback time 
of the last played frame plus the difference between the NPT time of the frame and the NPT time of the last played 
frame. 

The syntax for the metric "Jitter_Duration" is defined in sub-clause 8.3.2.1. 

In MBMS reception reporting will be done only once at the end of streaming, hence all the Jitter_Durations are summed 
up over each resolution duration and stored in the vector TotalJitterDuration. The unit of this metrics is expressed in 
seconds, and can be a fractional value. The number of individual events over the resolution duration are summed up and 
stored in the vector NumberOfJitterEvents. These two vectors are reported by the MBMS client as part of the reception 
report (sub-clauses 9.4.6 and 9.5.3). 

8.4.2.7 Content Access/Switch Time 

Content access/switch time is the time that elapses between the initiation of a content request/switch by the user and up 
to the time when the first packet of the content or media stream is received. 

The syntax for the metric "Content_Access_Time" is defined in sub-clause 8.3.2.1. 

The metric value indicates the content access/switch time and the unit of this metrics is expressed in seconds, and can 
be a fractional value. There can be only one measure and it can only take one value. "Content_Access_Time" is a 
session level parameter. This value is reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 
9.5.3). 

8.4.2.8 Network Resource 

The Net work_Re source identifies the cell which has been used during each measurement period. 

The syntax for the metric "Network_Resource" is as defined in sub-clause 8.3.2.1. 

The cell is identified by the Cell Global Identity (as described in 3GPP TS 23.003 [77]), which is a concatenation of 
MCC, MNC, LAC and CI. It shall be coded as a text string as follows: Starting with the most significant bit, MCC (3 
digits), MNC (2 or 3 digits depending on MCC value), LAC (4 hexadecimal digits) and CI (4 hexadecimal digits). 
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Only one cell shall be reported per measurement period, even if more than one cell has been used during a measurement 
period or if reception is done simultaneously from several cells. 

The cell used is stored in the vector NetworkResourceCellld. If the value in the vector for a resolution period is 
unchanged from the previous value, it is allowed to put the value "=" in the vector to indicate this. The vector is 
reported by the MBMS client as part of the reception report (sub-clauses 9.4.6 and 9.5.3). 

8.4.2.9 Average codec bitrate 

The average codec bitrate is the bitrate used for coding "active" media information during the measurement resolution 
period. 

For audio media "active" information is defined by frames containing audio. If the audio codec uses silence frames 
(SID-frames), these frames are not counted as "active", and the SID-frames and the corresponding DTX time periods 
are excluded from the calculation. Thus for audio media the average codec bitrate can be calculated as the number of 
audio bits received for "active" frames , divided by the total time, in seconds, covered by these frames. The total time 
covered is calculated as the number of "active" frames times the length of each audio frame. 

For non-audio media the average codec bitrate is the total number of media bits played out during the measurement 
resolution period, divided by the length of the playout period. The playout period length is normally equal to the length 
of the measurement resolution period, but if rebuffering occurs the playout period will be shorter (i.e. any rebuffering 
time shall be ignored when calculating the codec bitrate). 

The syntax for the metric "Average_Codec_Bitrate" is defined in sub-clause 8.3.2.1. 

The average codec bitrate value for each measurement resolution period shall be stored in the vector 
AverageCodecBitrate. The unit of this metrics is expressed in kbit/s and can be a fractional value. The vector is reported 
by the client as part of the reception report (sub-clauses 9.4.6 and 9.5.3). 

8.4.2.10 Codec information 

The codec information metrics contain details of the media codec used during the measurement resolution period. If the 
codec information is changed during the measurement resolution period, the codec information valid when each 
measurement resolution period ends shall be reported. The unit of this metric is a string value. No "white space" 
characters are allowed in the string values, and shall be removed if necessary. 

For audio media the codec information contains the audio codec type, represented as in an SDP offer, for instance 
"AMR-WB/16000/1". 

For video media, the codec information contains the video codec type, represented as in an SDP offer, for instance 
"H263 -2000/90000". Furthermore, the video profile and level used, as well as the image size used shall be reported. For 
instance "profile=0;level=45" for the profile and level information and "176x144" for the image size. In some cases the 
profile and level is reported together, for instance "profile-level-id=42e00a". Note that the image size reported for each 
measurement resolution period shall be the one actually used, not the maximum size allowed by the SDP negotiation. 

For timed text media, the codec information contains the text encoding, represented as in an SDP offer, for instance 
"3gpp-tt/1000". 

The syntax for the metric "Codec_Info", "Codec_ProfileLever' and "Codec_ImageSize" are defined in sub-clause 
8.3.2.1. 

The codec info, profile / level and codec image size value for each measurement resolution period shall be stored in 
the vectors Codeclnfo, CodecProfileLevel and CodecImageSize respectively. If the metric values in these vectors for a 
measurement resolution period are unchanged from the previous values in the respective vector, it is allowed to put the 
value "=" in the vector to indicate this. The Codeclnfo, CodecProfileLevel and CodecImageSize vectors are reported by 
the client as part of the reception report (sub-clauses 9.4.6 and 9.5.3). 

8.4.3 Example metrics initiation with SDP 

This following example shows the syntax of the SDP attribute for QoE metrics. The session level QoE metrics 
description (Initial buffering duration, rebufferings and network resource) are to be monitored with a measurement 
resolution of 20 seconds and reported at the end of the session. Also video specific description of metrics (corruptions) 
are to be monitored and reported at the end from the beginning of the stream until the time 40s. Finally, audio specific 
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description of metrics (corruptions) is to be monitored with a measurement resolution of 10s and reported at the end of 
the stream. 

SDP example: 

v=0 

o=- 3268077682 433392265 IN IP4 63.108.142.6 

s=QoE Enabled Session Description Example 

e=support@f oo . com 

c=IN IP4 0.0.0.0 

t = 

a=range :npt=0-83 . 660000 

a=3GPP-QoE -Metrics :metrics= { Initial_Buf f ering_Duration | Rebuf f ering_Duration | 

Network_Resource } ; rate=End ; resolut ion=2 
a=control : * 
m=video RTP/AVP 96 
b=AS:28 

a=3GPP-QoE -Metrics :metrics={ Corrupt ion_Durat ion} ;rate=End; range :npt=0-40 
a=control : trackID=3 
a=rtpmap:96 MP4V-ES/1000 
a=range:npt=0-83 .666000 

a=fmtp : 96prof lie- level- id=8;config=000001b008000001b50900012000 
m=audio RTP/AVP 98 
b=AS : 13 

a=3GPP-QoE -Metrics : met rics={ Corrupt ion_Durat ion} ; rat e=End; resolut ion= 10 
a=control : trackID=5 
a=rtpmap:98 AMR/8000 
a=range:npt=0-83 .660000 
a=fmtp:98 octet-align=l 
a=maxpt ime : 2 

8.5 Using MBMS Streaming delivery on Unicast 

If the MBMS UE supports MBMS streaming delivery on unicast, then MBMS Streaming shall perform the functions of 
a PSS client [47] to deliver content when MBMS Bearers are not usable or available and if an 

alternativeUnicastDelivery element is available for the delivery method in the MBMS User Service Description. Note, 
if an alternativeUnicastDelivery element is available, it is presumed that the same content is offered over both PSS and 
MBMS. If more than one unicastAccessURI element is available in the alternativeUnicastDelivery element, then the UE 
shall randomly choose one URI to be used for unicast access to the service. 

MBMS and PSS define Quality of Experience (QoE) metrics features. The UE shall not mix MBMS and PSS QoE 
metrics gatherings and/or reports. QoE is negotiated, gathered and reported separately for PSS and MBMS. 

The UE may compare the SSRC values of PSS and MBMS flows. If the UE detects that the same SSRC value is used 
for PSS and MBMS flows, then the UE should assume that the same wallclock time and same random RTP timestamp 
offset is used for the flows with the same SSRC value. This gives the UE an advantage for the synchronization onto the 
flows. The UE does not need to wait for new, flow specific RTCP packets. 

The BM-SC and the PSS servers which provide for unicast access to the MBMS service shall be time synchronized. 
The PSS server and the UE should support UTC clock time format in the "Range" header field as defined in [88]. 

The UE may request a specific start time of the PSS session by indicating a UTC clock time in the "Range" header field 
of the PLAY request. The UTC clock time represents the requested streaming start point according to the timeline of the 
BM-SC. This time may be calculated using the NTP timestamp of the last received RTCP sender reports. Otherwise, the 
UE may either specify an NPT range using the "now" value as a start point of the PSS session or it may completely 
omit the Range header field. 

If the PSS server does not support time shifting and the request contains a range indication (other than "now") then the 
PSS server shall reply with the actual range that will be played back. Examples of this are an NPT range header field 
using "now" or the selected start time in UTC clock time. 

A unicastAccessURI element of an alternativeUnicastDelivery element in the deliveryMethod element of the User 
Service Description may contain an RTSP URI or a reference to an PSS SDP file. 
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Associated delivery procedures 



9.1 Introduction 

Associated delivery procedures describe general procedures, which start before, during or after the MBMS data 
transmission phase. They provide auxiliary features to MBMS user services in addition, and in association with, 
MBMS delivery methods and their sessions. Those procedures that shall only be permitted after the MBMS Data 
transmission phase may also be described as post-delivery procedures. 

To enable future backwards compatibility, clause 9 specifies generic and extensible techniques for a potentially wide 
range of associated delivery procedures. 

Clauses 9.3 and 9.4 specify the associated delivery procedures that are initiated only after an MBMS data transmission 
phase. 

The present document describes the following associated delivery procedures: 

• File repair, for post-delivery repair of files initially delivered as part of an MBMS download session. 

• Content reception reporting of files delivered to an MBMS UE. 

These procedures are enabled by establishing a point-to-point connection; and using the MBMS session parameters, 
received during User Service Discovery/Announcement, to communicate the context (e.g. file and session in question) 
to the network and the MBMS sender infrastructure. To avoid network congestion in the uplink and downlink 
directions, and also to protect servers against overload situations, the associated delivery procedures from different 
MBMS UEs shall be distributed over time and resources (network elements). 

An instance of an "associated procedure description" is an XML file that describes the configuration parameters of one 
or more associated delivery procedures. 

MBMS Download receivers shall support the file repair procedure as defined in sub-clause 9.3. 

MBMS Download receivers shall support the reception reporting procedure as defined in sub-clause 9.4. 

MBMS Streaming receivers shall support reception reporting procedures (StaR and StaR-all report types) as defined in 
sub-clause 9.4. 

9.2 Associated Procedure Description 

An associated procedure description instance (configuration file) for the associated delivery procedures may be 
deUvered to the MBMS clients: 

• during a User Service Discovery / Announcement prior to the MBMS Download delivery session along with the 
session description (out-of-band of that session); or 

• in-band within a MBMS Download delivery session. 

The most recently delivered configuration file (i.e. the one with the highest version number - as given from the 
envelope, see sub-clause 11. 1.3) shall take priority, such that configuration parameters received prior to, and out-of- 
band of, the download session they apply to are regarded as "initial defaults", and configuration parameters received 
during, and in-band with the download session, overwrite the earlier received parameters. Thus, a method to update 
parameters dynamically on a short time-scale is provided but, as would be desirable where dynamics are minimal, is not 
mandatory. 

During the User Service Discovery / Announcement Procedure, the associated procedure description instance is clearly 
identified using a URI, to enable UE cross-referencing of in and out-of-band configuration files. 

The MIME application type "application/mbms-associated-procedure-description-i-xmr' as defined in clause C.7 
identifies associated delivery procedure description instances (configuration files). 

In XML, each associated delivery procedure entry shall be configured using an "associatedProcedureDescription" 
element. All configuration parameters of one associated delivery procedure are contained as attributes of an 
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"associatedProcedureDescription" element. The elements (e.g. "postFileRepair" and "postReceptionReport") of 

an "associatedProcedureDescription" element identify which associated procedure(s) to configure. The associated 
delivery procedure description is specified formally as an XML schema in sub-clause 9.5.1. 

9.3 File Repair Procedure 

9.3.1 Introduction 

The purpose of the File Repair Procedure is to repair lost or corrupted file fragments from the MBMS download data 
transmission. When in multicast/broadcast environment, scalability becomes an important issue as the number of 
MBMS clients grows. Three problems must generally be avoided: 

• Feedback implosion due to a large number of MBMS clients requesting simultaneous file repairs. This would 
congest the uplink network channel. 

• Downlink network channel congestion to transport the repair data, as a consequence of the simultaneous clients 
requests. 

• File repair server overload, caused again by the incoming and outgoing traffic due to the clients' requests arriving 
at the server, and the server responses to serve these repair requests. 

The three problems are interrelated and must be addressed at the same time, in order to guarantee a scalable and 
efficient solution for MBMS file repair. 

The principle to protect network resources is to spread the file repair request load in time and across multiple servers. 

The MBMS chent: 

1 . Identifies the end of transmission of files or sessions. 

2. Identifies the missing data from an MBMS download. 

3. Calculates a random back-off time and selects a file repair server randomly out of a list. 

4. Sends a repair request message to the selected file repair server at the calculated time. 

When a MBMS download session of repair data is configured in the associated delivery descriptions, a MBMS client 
should wait for repair data in the defined MBMS download session on its MBMS bearer - except where the UE is 
prevented from doing so due to limited simultaneous context activation capability. 

Then the file repair server: 

1 . Responds with a repair response message either containing the requested data, redirecting the client to an 
MBMS download session, redirecting the client to another server, or alternatively, describing an error case. 

The BM-SC may also send the repair data on a MBMS bearer (possibly the same MBMS bearer as the original 
download) as a function of the repair process. 

The random distribution, in time, of repair request messages enhances system scalability to the total number of such 
messages the system can handle without failure. 

9.3.2 Starting Time of the Associated Delivery Procedure for MBMS 
Download Delivery 

FLUTE File Delivery Table (FDT) Instances include an "expires" attribute, which defines the expiration time of the 
FDT instance. The sender must use an expiry time relative to the current time at the BM-SC. According to 
RFC 3926 [9], "the receiver SHOULD NOT use a received FDT Instance to interpret packets received beyond the 
expiration time of the FDT Instance". 

The starting time of Associated Delivery Procedure for the MBMS download is the expiration time of the FDT instance 
at the latest. 

The MBMS UE may also choose to start the Associated Delivery Procedure before the FDT instance expires 
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• when it has received an end-of -object (B-flag) for an object or 

• when an end-of-session (A-flag) is received before the FDT instance expires. Note, the end-of session (A- 
flag) indicates, that no more objects nor FDT instances will be transmissed by the BM-SC. 

If the MEMS UE is not capable of receiveing an MBMS transmission while using an interactive bearer, the MBMS UE 
shall ignore the end-of-object flags (B-flag). 

When a particular file (URI) is present in several FDT Instances with different TOI values, then the FDT Instance with 
the highest FDT Instance ID defines the TOI for the most recent instance of the file and determines the end of 
transmission time for that file. A UE shall only determine transmission completeness for a file for the most recent 
instance of the file - and shall not use FDT Instance expiry time to determine transmission completeness for any other 
(TOI) instances of a file (fileURI). 

NOTE 1 : The intention of this sub-clause is to just start the Associated Delivery Procedure back-off timer for the 
more recent instance version of a file with respect to the FLUTE transmission session. 

When a particular file (URI) is present in more than one FDT Instance with the same TOI value, then the end of 
transmission time is defined by the expiration time of the latest FDT Instance to expire. 

If an FDT Instance is received describing the file after this time (giving an FDT Instance expiry time in the future and a 
different TOI value) the UE shall determine that the transmission of the file is incomplete - i.e. that more packets may 
arrive within the MBMS download session for that file, Torgetting' its previous file transmission complete 
determination. 

NOTE 2: This effectively resets and stops any running timers already initiated for an associated delivery procedure 
for that file. 

If the MBMS UE receives an end-of-object packet (with FLUTE header B flag set true) the MBMS UE shall determine 
that the transmission of that object is complete, and shall interpret that as file transmission complete if no, more recent, 
TOIs are described for the same file (URI) in any received and unexpired FDT Instance(s). 

If the MBMS UE determines that the download session is complete (as specified in sub-clause 9.4.2) then it shall 
interpret this also that all the transmissions of all files (and TOIs) described by all FDT Instances, received from that 
session, are complete. 

9.3.3 Identification of Missing Data from an MBMS Download 

The session description and the MBMS download delivery protocol, FLUTE, provide the client with sufficient 
information to determine the source block and encoding symbol structure of each file. From this a client is able to 
determine which source symbols should have been transmitted but have not been received. The client is also able to 
determine the number of symbols it has received for each source block of each file, and thus the number of further 
symbols required to decode the block. 

Thus, an MBMS client is able to identify any source symbols lost in transmission, and the number (and ESI values 
where appropriate) of required source and/or repair symbols that would complete the reconstruction of a source block 
(of a file). 

When the MBMS EEC scheme is used, the MBMS client shall consider already received repair symbols when making 
the determination of the further symbols required. In this case, the client should either: 

• identify a minimal set of specific symbols that, combined with the already received symbols, 
allows the MBMS FEC decoder to recover the file, or 



• 



identify a number, r, of symbols such that reception of r previously unreceived symbols will allow 
the MBMS FEC decoder to recover the file. 



9.3.4 Back-off Timing the Procedure Initiation Messaging for Scalability 

This clause describes a back-off mode for MBMS download to provide information on when a receiver, that did not 
correctly receive some data from the MBMS sender during a transmission session, can start a request for a repair 
session. In the following it is specified how the information and method a MBMS client uses to calculate a time 
{back-off time), instance of the back-off mode, to send a file repair message to the MBMS server. 
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The back-off mode is represented by a back-off unit, a back-off value, and a back-off window. The two latter 
parameters describe the back-off time used by the MBMS chent. 

The back-off unit (in the time dimension) defaults to seconds and it is not signalled. 

The back-off time shall be given by an offset time (describing the back-off value) and a random time period (describing 
the back-off window) as described in the following clauses. 

An MBMS client shall generate random or pseudo-random time dispersion of repair requests to be sent from the 
receiver (MBMS client) to the sender (MBMS server). In this way, the repair request is delayed by a pre-determined 
(random) amount of time. 

The back-off timing of repair request messages (i.e. delaying the sending of repair requests at the receiver) enhances 
system scalability to the total number of such messages the system can handle without failure. 

9.3.4.1 Offset time 

The OffsetTime refers to the repair request suppression time to wait before requesting repair, or in other words, it is the 
time that a MBMS client shall wait after the end of the MBMS data transmission to start the file repair procedure. An 
associated procedure description instance shall specify the wait time (expressed in back-off unit) using the "offset-time" 
attribute. 

9.3.4.2 Random Time Period 

The Random Time Period refers to the time window length over which a MBMS client shall calculate a random time for 
the initiation of the file repair procedure. The method provides for statistically uniform distribution over a relevant 
period of time. An associated procedure description instance shall specify the wait time (expressed in back-off unit) 
using the "random-time-period" attribute. 

The MBMS client shall calculate a uniformly distributed Random Time out of the interval between and Random Time 
Period. 

9.3.4.3 Back-off Time 

The sending of the file repair request message shall start at Back-off Time = offset-time -n Random Time, and this 
calculated time shall be a relative time after the MBMS data transmission. The MBMS client shall not start sending the 
repair request message before this calculated time has elapsed after the initial transmission ends. 

9.3.4.4 Reset of the Back-off Timer 

The reception of an updated (higher version number) associatedDeliveryProcedureDescription and/or an updated 
sessionDescription shall overwrite the timer parameters used in the back-off algorithm. Except in the case that the 
offset-time, random-time -period and session end time parameters are identical to the earlier version; the back-off time 
shall be recalculated. For currently running timers this requires a reset. 

9.3.5 File Repair Server Selection 

9.3.5.1 List of Server URIs 

A list of file repair service URIs is provided as elements of the Associated Delivery procedure fragment's 
postFileRepair element. Service URIs host identity may also be given as IP addresses, which may be used to avoid a 
requirement for DNS messaging. The file repair service URIs of a single associated delivery procedure description shall 
be of the same type, e.g. all IP addresses of the same version, or all domain names. The number of URIs is determined 
by the number of "serviceURI" elements, each of which shall be a child-element of the "procedure" element. The 
"serviceURI" element provides the references to the file repair server's resource via the "xs:anyURI" value. At least one 
"serviceURI" element shall be present. 

9.3.5.2 Selection from the Server URI List 

The MBMS client randomly selects one of the service URIs from the list, with uniform distribution. 
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9.3.6 File Repair Request Message 



Once missing file data is identified, the MBMS client sends one or more messages to a file repair server requesting 
transmission of data that allows recovery of missing file data. All file repair requests and repair responses for a 
particular MBMS transmission shall take place in a single TCP session using the HTTP protocol (RFC 2616 [18]). The 
repair request is routed to the file repair server IP address resolved from the selected "serviceURI". 

The timing of the opening of the TCP connection to the server, and the first repair request, of a particular MBMS client 
is randomized over a time window as described in sub-clause 9.3.2. If there is more than one repair request to be made 
these are sent immediately after the first. 

When a MBMS UE identifies symbols in repair requests these shall be source symbols, and should include all the 
missing source symbols of the relevant source block. Note, these represent information for the file repair server and the 
BM-SC may use these and/or redundant symbols in providing the necessary repair data. 

9.3.6.1 File Repair Request Message Format 

After the MBMS download session, the receiver identifies a set of encoding symbols which allows recovery of the 
missing file data and requests for their transmission in a file repair session. Specific encoding symbols are uniquely 
identified by the combination (URI, SBN, ESI). 

The file repair request shall either include the URI of the file for which it is requesting the repair data or an identifier of 
a set of files. URI is required to uniquely identify the file (resource) and is found from the download delivery method 
(the FLUTE FDT Instances describe file URIs). Additionally, the repair request for single files shall contain an 
indication of the MD5 hash value of the file, if present in the FDT instance declaring the file from which data is being 
requested. The MD5 hash value is used to identify a specific version of the file. The (SBN, ESI) pair uniquely identifies 
an encoding symbol. For completely missed files, a Repair Request may give only the URI of the file and optionally the 
MD5 hash value of the file. If the MD5 hash value is not present, the server shall respond with the latest version of the 
file. 

A set of files may be fetched using the File Repair server. A client may request all files from a specific FDT instance or 
a specific logical group of a particular MBMS User Services. 

The client makes a file repair request using the HTTP (RFC 2616 [18]) request method GET. Further arguments are 
encoded into the URI query part (RFC 3986 [19]) as defined below and included in the HTTP GET request. If a number 
of previously unreceived symbols are requested for a specific Source Block, then the SBN is provided along with the 
ESI of the symbol, which is subsequent in the symbol sequence to the latest received symbol for that source block and 
the number of symbols requested. If a number of previously unreceived source blocks are requested for a specific 
file, the URI should be provided along with an SBN range starting from the first missing source block and ending with 
the SBN of the last missing source block of the contiguous set of source block. Examples for requesting contiguous 
and non-contiguous ranges of symbols and source blocks or even entire files or group of files are given below. 

For example, assume that in a MBMS download session a 3gp file with URI = www.example.com/news/latest.3gp was 
delivered to an MBMS client. After the MBMS download session, the MBMS client recognized that it did not receive 
two packets with SBN = 5, ESI = 12 and SBN=20, ESI = 27. If the repair service URI (from the associated delivery 
procedure meta data fragment) is http://mbmsrepairl.example.com/path/repair script and the MD5 value of that file is 
"ODZiYTU10TFkZGY2NWY50Dh==", then the HTTP GET request is as follows: 

GET /path/repair_script?fileURI=www.example. com/news/latest. 3gp&Content-MD5= 
ODZiYTU10TFkZGY2NWY50Dh== &SBN=5;ESI=12&SBN=20;ESI=27 HTTP/1.1 

Host: mbmsrepairl.example.com 

A file repair session shall be used to recover the missing file data from a single MBMS download session only. If more 
than one file were downloaded in a particular MBMS download session, and, if the MBMS client needs repak data for 
more than one file received in that session, the MBMS client shall send separate HTTP GET requests for each file. 

An HTTP client implementation might limit the length of the URL to a finite value, for example 256 bytes. In the case 
that the length of the URL-encoded (SBN, ESI) data exceeds this limit, the MBMS chent shall distribute the 
URL-encoded data into multiple HTTP GET requests. 

In any case, all the HTTP GETs of a single file repair session shall be performed within a single TCP session and they 
shall be performed immediately one after the other. 
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In the following, we give the details of the syntax used for the above request method in ABNF. 

In this case an HTTP GET with a normal query shall be used to request the missing data, according to HTTPl.l 
[RFC2616 [18]] 

• repair_request_http_URL = repair_service_URI "?" query 

• repair_service_URI = <selected serviceURI from the Associated Delivery Procedure Description> 
Where, for MBMS File Repair Request: 

• query = std_query I alt_query 

• std_query = file_uri ["&" content_md5] *( "&" sbn_info) 

• file_uri = "fileURI=" URI-reference; URI-reference is as defined in [19]. 

• content_md5 = "Content-MD5=" 1 *(ALPHA / DIGIT / "+" / 7" / "=") 

• sbn_info = "SBN=" sbn_range 

• sbn_range = ( sbnA [ "-" sbnZ ] ) / ( sbnA [ ";" esijnfo] ) 

• esi_info = "ESI=" ((esi_range *( "," esi_range ) ) ) / (esiA "+" number_symbols) 

• esi_range = esiA [ "-" esiZ ] 

• sbnA = 1 *DIGIT; the SEN, or the first of a range of SBNs 

• sbnZ = 1 *DIGIT; the last SBN of a range of SBNs 

• esiA = 1 *DIGIT; the ESI, or the first of a range of ESIs 

• esiZ = 1 *DIGIT; the last ESI of a range of ESIs 

• number_symbols = 1 *DIGIT; the number of additional symbols requked 

• alt_query = service_id "&" ( fdt_inst_id I fdt_group_id ) 

• service_id = "serviceld=" <value of the serviceld attribute of the User Service Description> 

• fdt_inst_id = "fdtlnstanceld=" <as defined in clause 3.4. 1 of [9] or in clause 7.3> 

• fdt_group_id = "fdtGroupId=" <as defined in clasue 7.2.9> 

Thus, the following symbols adopt a special meaning for MBMS download URI: ?- + ,;& = 

One example of a query on encoding symbol 34 of source block 12 of a music file 
"www.example.comm/greatmusic/numberl.aac" using the provided repair service URI 
"http://mbmsrepairl .example.com/path/repair_script" is: 

• http://mbmsrepairl . example. com/path/repair_script?fileURI= 
www. example. com/greatmusic/numberl.aac&SBN=12:ESI=34 

An example of requesting an entire file is 

• http://mbmsrepairl . example. com/path/repair_script?fileURI= www.example.com/greatmusic/numberl.aac 

An example of requesting a specific source block from a specific file version is 

• http://mbmsrepairl .example.com/path/repair_script?fileURI= 

www.example.com/greatmusic/numberl.aac &Content-MD5=ODZiYTU10TFkZGY2NWY50Dh== 

For messaging efficiency, the formal definition enables several contiguous and non-contiguous ranges to be expressed, 
as well as a number of symbols with ESIs of a given value or above in a single query: 

• An entire file (like in the above example). 
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• A symbol of a source block (e.g. ...&SBN=12;ESI=23). 

• A range of symbols for a certain source block (e.g. ...&SBN=12;ESI=23-28). 

• A number of symbols with ESIs of a given value or above (e.g. . . .&SBN=12;ESI=120+10). 

• A list of symbols for a certain source block (e.g. ...&SBN=12;ESI=23,26,28). 

• All symbols of a source block (e.g. ...&SBN=12). 

• All symbols of a range of source blocks (e.g. ...&SBN=12-19). 

• non-contiguous ranges (e.g.l. ...&SBN=12;ESI=34&SBN=20;ESI=23 also, 
e.g. 2. ...&SBN=12-19&SBN=28;ESI=23-59&SBN=30;ESI=101). 

An example to request all file of a particular FDT instance is given below: 
• http://mbmsrepair 1 .example.com/path/repair_script?serviceld=urn:3gpp;00 1 1 20 1 23hotdog&fdtInstanceId= 1 2 



9.3.7 File Repair Response Message 



Once the MBMS file repair server has assembled a set of encoding symbols that contain sufficient data to allow the UE 
to reconstruct the file data from a particular file repair request, the MBMS file repair server sends one message to the 
UE. Each file repair response occurs in the same TCP and HTTP session as the repair request that initiated it. 

An MBMS client shall be prepared for any of these 5 response scenarios: 

• The server returns a repair response message where a set of encoding symbols forms an HTTP payload as 
specified below (see 9.3.7.2 for details). 

• The server returns the requested file or file groups (see 9.3.7.4 for details). 

• The server redirects the client to a broadcast/multicast delivery (an MBMS download session). 

• The server redirects the client to another file repair server (if a server is functioning correctly but is temporarily 
overloaded). 

• An HTTP error code is returned (note that sub-clause 9.3.8 describes the case of no server response). 

For (reasonably) uniformly distributed random data losses, immediate point-to-point HTTP delivery of the repair data 
will generally be suitable for all clients. However, broadcast/multicast delivery of the requested data may be desirable in 
some cases: 

• A repeat MBMS download (all or part of the files from a download session) is already scheduled and the BM-SC 
prefers to handle repairs after that repeat MBMS download. 

• Many UEs request download data (over a short period of time) indicating that broadcast/multicast delivery of the 
repaired data would be desirable. 

In this case a redirect to the broadcast/multicast repair session for UEs that have made a repair request would be 
advantageous. 

9.3.7.1 File Repair Response Messages Codes 

In the case that the file repair server receives a correctly formatted repair request which it is able to understand and 
properly respond to with the appropriate repair data, the file repair server shall attempt to serve that request without an 
error case. 

For a direct point-to-point HTTP response with the requested data, the file response message shall report a 200 OK 
status code and the file repair response message shall consist of HTTP header and file repair response payload (HTTP 
payload), as defined in sub-clause 9.3.7.2. If the client receives a 200 OK response with fewer than all the quantity of 
requested symbols it shall assume that the file repair server wishes the missing symbols to be requested again (due to its 
choice or inability to deliver those symbols with this HTTP response). 
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For a redirect case the file repair server uses the HTTP response status code 302 (Found - Redirection) to indicate to the 
UE that the resource (file repair data) is temporarily available via a different URL The temporary URI is given by the 
Location field in the HTTP response. In the case of a redirect to another file repair server, this temporary URI shall be 
the URL of that repair server. 

In the case of a redirect to a broadcast/multicast delivery, the temporary URI shall be the URI of the Session 
Description (SDP file) of the broadcast/multicast (repair) session as described in sub-clause 9. 3.5. 3. Other HTTP status 
codes (RFC 2616 [18]) shall be used to support other cases. Other cases may include server errors, client errors (in the 
file repair request message) and server overload. 

In case the file repair server does not find the requested file (file with given fileURI is found), the server shall respond 
with "400 Bad Request" and optionally with "0001 File not found" in the response body. As a result, the MBMS UE 
may choose another file repair server as defined in clause 9.3.5. 

In case the file repair server does not find the requested version of the requested file (file with given fileURJ is found 
but Content-MD5 is not found), the server shall respond with "400 Bad Request" and optionally with "0002 Content- 
MD5 not valid" in the response body. As a result, the MBMS UE may chose another file repair server as defined in 
clause 9.3.5. Or the MBMS UE may request the latest version of the file and discard the previously received chunks of 
the file. Note, the MBMS UE can request the latest version of a file by using only the fileURJ argument in the file repair 
request. 

Note. In case of repetitive server errors, the client is not expected to go through the complete list of available file 
repair servers, and may abandon after a limited number of attempts. 

In case the file repair server does not find any of the requested SBN or ESI values, it shall respond with the "400 Bad 
Request" and optionally with "0003 SBN or ESI out of range" in the respon se body. As a result, the UE should 
discard all received chunks of the file and request the entire file from the file repair server. 

In case the file repair server receives unknown query line arguments, it shall respond with "501 Not Implemented". The 
server should add the HTTPl.l "Server" header with the value "MBMS/6". As a result, the client should try to fetch the 
entire file from the file repair server. Note, this behaviour is intended to make the file repair service forward compatible 
and allow addition of new function in later releases. 

In case the file repair server does not find the requested serviceld value, it shall respond with the "400 Bad Request" 
and optionally with "0004 Serviceld not found" in the response body. As a result, the UE should request the needed 
file separately using the fileURI query line argument. 

In case the file repair server does not find the requested fdtlnstanceld value, it shall respond with the "400 Bad Request" 
and optionally with "0005 fdtlnstanceld not found" in the response body. As a result, the UE should request the 
needed file separately using the fileURI query line argument. 

In case the file repair server does not find the requested fdtGroupId value, it shall respond with the "400 Bad Request" 
and optionally with "0006 fdtGroupId not found" in the response body. As a result, the UE should request the needed 
file separately using the fileURI query line argument. 

HTTP responds error messages may contain a message body, which gives a more detailed error message. The MIME 
type of such message body shall be in text/plain. The syntax of the HTTP error message body is defined in ABNF [23] 
as follows: 

http-error-body = error-code (SP / HTAB) error-description CRLF 

error-code = 4DIGIT 

error-description = 1*(SP / VCHAR) 

Note that the following error messages MAY be used in the message body of the HTTP response error messages. 

0001 File not found 

0002 Content-MD5 not valid 

0003 SBN or ESI out of range 

0004 Serviceld not found 

0005 fdtlnstanceld not found 
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0006 fdtGroupId not found 

9.3.7.2 File Repair Response Message Format for HTTP Carriage of Repair Data 

The file repair response message consists of HTTP header and file repair response payload (HTTP payload). 
The HTTP header shall provide: 

• HTTP status code, set to 200 OK for the case of a successful request. 

• Content type of the HTTP payload (see below). 

NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism. 

The Content-Type shall be set to "application/simpleSymbolContainer", which denotes that the message body is a 
simple container of encoding symbols as described below. 

This header is as follows: 

• HTTP/1.1 200 OK 

• Content-Type: application/simpleSymbolContainer 

NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism. 

Encoding symbols are included in the response in groups. Each group is preceded by an indication of the number of 
symbols within the group and an EEC Payload ID coded according to the EEC scheme used for the original file delivery 
session. The EEC Payload ID identifies all the symbols in the group in the same way that the FEC Payload ID of an 
EEC source or repair packet identifies all the symbols in the packet. The file repair response payload is constructed by 
including each FEC Payload ID and Encoding Symbol group one after another (these are already byte aligned). The 
order of these pairs in the repair response payload may be in order of increasing SBN, and then increasing ESI, value; 
however no particular order is mandated. 

A single HTTP repair response message shall contain, at the most, the same number of symbols as requested by the 
respective HTTP repair request message. 

The UE and file repair server already have sufficient information to calculate the length of each encoding symbol and 
each FEC Payload ID. All encoding symbols are the same length; with the possible exception of the last source 
encoding symbol in the repair response. All FEC Payload IDs are the same length for one file repair request-response as 
a single FEC Scheme is used for a single file. 

Figure 17: deleted 
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Figure 18 illustrates the complete file repair response message format (box sizes are not indicative of the relative 
lengths of the labelled entities). 



HTTP Header 


Length 
Indicator 


FEC Payload ID 


Encoding Symbols 


Length 
Indicator 


FEC Payload ID 


Encoding Symbols 




Length 
Indicator 


FEC Payload ID 


Encoding Symbols 



Length Indicator (2 bytes): indicates tiie number of encoding symbols in tlie group (in networl< byte order, i.e. tiigti 

order byte first) 
FEC Payload ID: indicates wtiicli encoding symbols are included in the group. The format and interpretation of the 

FEC Payload ID are dependent on the FEC Scheme in use. 
Encoding Symbols: contain the encoding symbols. All the symbols shall be the same length. 



9.3.7.3 



Figure 18: File Repair Response lUlessage Format 



File Repair Response for Broadcast/Multicast of Repair Data 



Details of how a file repair server decides, or is instructed, to use broadcast/multicast repair instead of point-to-point 
over HTTP are implementation specific and beyond the scope of the present document. 

Prior to the decision to use broadcast/multicast repair, each repair response shall be provided by HTTP according to 
sub-clause 9.3.7.2. 

The file repair server uses the HTTP response status code 302 (Found - Redirection) to indicate to the UE that the 
resource (file repair data) is temporarily available via a different URL The temporary URI is given by the Location field 
in the HTTP response and is the URI of the Session Description (SDP file) of the broadcast/multicast repair session. 

Where feasible, it is recommended that the same download session that delivered the original data be used for the 
broadcast/multicast repair. If this conflicts with the session end time limit of the Session Description then a new version 
of the Session Description shall be sent with an updated (extended) session end time. This shall be sent in-band of that 
download session. 

In some cases this may not be feasible and a different (possibly new) download session may be defined for the repair. 

The SDP file for broadcast/multicast repair session may be carried as payload (entity-body) in the HTTP response - 
which is especially useful if the broadcast/multicast repair session is a new (or recently end time modified) FLUTE 
download session and other means of service announcement prior to this were not feasible. 

The delivery method's associatedDeliveryProcedureDescription may be updated and the new version transmitted in- 
band with the download session so that currently active client back-off timers are reset, thus minimizing additional 
client requests until after the broadcast/multicast repair session. The server shall be prepared for additional requests in 
any case as successful reception of the updated associatedDeliveryProcedureDescription can not be assured in all cases. 
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The existence of a broadcast/multicast file repair session is signalled by the inclusion of the optional bmFileRepair 
procedure in the updated Associated Delivery procedure description. This is signalled by the bmFileRepair element 
with a single "sessionDescriptionURI" attribute of type "xs:anyURI" which specifies the URI of the broadcast/multicast 
file repair session's session description. 

In the cases where the same IP addressing is used for the broadcast/multicast repair session as the original download 
session, the UE simply shall not leave the group. Otherwise, the UE shall join to the MBMS bearer for the repair 
session as it would for any MBMS session. 

A broadcast/multicast file repair session behaves just as an MBMS download session, and the determination of end of 
files and session, and use of further associated delivery procedures uses the same techniques as specified for the MBMS 
download delivery method. 

9.3.7.4 File Repair Response Message Format for HTTP carriage of Complete Files 

The file repair response message consists of HTTP header and one or more complete files. 
The HTTP header shall provide; 

• HTTP status code, set to 200 OK for the case of a successful response. 

• Content type shall be set to multipart/related 

NOTE: Other HTTP headers (RFC 2616 [18]) may also be used but are not mandated by this mechanism. 

The server shall encapsulate the requested files into a multipart mime container. Each part of the multipart mime shall 
contain at least the Content-Location of the embedded files. 

9.3.8 Server Not Responding Error Case 

In the error case where a UE determines that the its selected file repair server is not responding it shall return to the 
serverURI list of repair servers and uniformly randomly select another server from the list, excluding any servers it has 
determined are not responding. All the repair requests message(s) from that UE shall then be immediately sent to the 
newly selected file repair server. 

If all of the repair servers from the serverURI list are determined to be not responding, the UE may attempt an HTTP 
GET to retrieve a, potentially new, instance of the session's Associated Procedure Description; otherwise UE behaviour 
in this case is unspecified. 

A UE determines that a file repair server is not responding if any of these conditions apply: 

1 . The UE is unable to establish a TCP connection to the server. 

2. The server does not respond to any of the HTTP repair requests that have been sent by the UE (it is possible that 
second and subsequent repair requests are sent before the first repair request is determined to be 
not-responded-to). 

3. The server returns an unrecognized message (not a recognizable HTTP response). 

4. The server returns an HTTP server error status code (in the range 500 to 505). 

9.4 The Reception Reporting Procedure 

Following successful reception of content whether through point-to-multipoint MBMS bearers only, unicast bearers 
only, or using both point-to-multipoint and point-to-point bearers, a reception reporting procedure can be initiated by 
the MBMS Receiver (UE) to the BM-SC. 

For MBMS Download Delivery method, the reception reporting procedure is used to report the complete reception of 
one or more files. For MBMS Streaming Delivery method, the reception reporting procedure is used to report statistics 
on the stream. 

If the BM-SC provided parameters requiring reception reporting confirmation then the MBMS Receiver shall confirm 
the content reception. 
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If reception reporting is requested for statistical purposes the BM-SC may specify the percentage subset of MBMS 
receivers it would like to perform reception reporting. 

Transport errors can prevent an MBMS Receiver from deterministically discovering whether the reception reporting 
associated delivery procedure is described for a session, and even if this is successful whether a sample percentage is 
described. An MBMS Receiver shall behave according to the information it has even when it is aware that this may be 
incomplete. 

The MBMS Receiver: 

1. Identifies the complete reception of a content item (e.g. a file). See sub-clauses 9.4. land 9.4.2. 

2. Determines the need to report reception. See sub-clause 9.4.3. 

3. Selects a time (Request time) at which a reception report request will be sent and selects a server from a list - 
both randomly and uniformly distributed. See sub-clauses 9.4.4 and 9.4.5. 

4. Sends a reception report request message to the selected server at the selected time. See sub-clause 9.4.6. 

Then the server: 

1. Responds with a reception report response message either describing a success or an error case. See sub-clause 
9.4.7. 

9.4.1 Identifying Complete File Reception from MBMS Download 

A file is determined to be completely downloaded when it is fully received and reconstructed by MBMS reception with 
FEC decoding (if FEC is actually used) and/or a subsequent File Repair Procedure (sub-clause 9.3). The purpose of 
determining file download completeness is to determine when it is feasible for a UE to compile the RAck reception 
report for that file. 

9.4.2 Identifying Complete MBMS Delivery Session Reception 

Delivery sessions (download and streaming) are considered complete when the "time to" value of the session 
description (from "t=" in SDP) is reached. Where the end time is unbounded (time to = 0) then this parameter is not 
used for identifying completed sessions. 

Delivery sessions are also considered complete when the UE decides to exit the session - where no further data from 
that session will be received. In this case the UE may or may not deactivate the MBMS bearer(s). 

For MBMS download sessions, FLUTE provides a "Close session flag" (see sub-clause 7.2.7) which, when used, 
indicates to the UE that the session is complete. 

9.4.3 Determining Whether a Reception Report Is Required 

Upon full reception of a content item or when a session is complete, the MBMS Receiver must determine whether a 
reception report is required. An Associated Delivery Procedure Description indicates the parameters of a reception 
reporting procedure (which is transported using the same methods as the ones that describe File Repair). 

A delivery method may associate zero or one associated delivery procedure descriptions with an MBMS delivery 
session. Where an associated delivery procedure description is associated with a session, and the description includes a 
postReceptionReport element, the UE shall initiate a reception reporting procedure. Reception reporting behaviour 
depends on the parameters given in the description as explained below. 

The Reception Reporting Procedure is initiated if: 

a. A postReceptionReport element is present in the associated procedure description instance, or the default QoE 
reporting according to sub-clause 8.3.2.2 is activated. 

One of the following will determine the UE behaviour: 

b. reportType is set to RAck (Reception Acknowledgement). Only successful file reception is reported without 
reception details. 
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c. reportType is set to StaR (Statistical Reporting for successful reception). Successful file reception is reported (as 
with RAck) with reception details for statistical analysis in the network. 

d. reportType is set to StaR-all (Statistical Reporting for all content reception). The same as StaR with the addition 
that failed reception is also reported. StaR-all is relevant to both streaming and download delivery. 

e. The default OMA-DM QoE reporting configuration is activated according to sub-clause 8.3.2.2. QoE reporting 
is in this case done according to the content of the "Rules" leaf in the 3GPP_MBMSQOE MO. 

The reportType attribute is optional and behaviour shall default to RAck when it is not present. 

The samplePercentage attribute can be used to set a percentage sample of receivers which should report reception. This 
can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink 
signalling. The samplePercentage takes on a value between and 100, including the use of decimals. It is 
recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision). 

The samplePercentage attribute is optional and behaviour shall default to 100 (%) when it is not present. The 
samplePercentage attribute may be used with StaR and StaR-all, but shall not be used with RAck. 

When the samplePercentage is not present or its value is 100 each UE which entered the associated session shall send a 
reception report. If the samplePercentage were provided for reportType StaR and StaR-all and the value is less than 
100, the UE generates a random number which is uniformly distributed in the range of tolOO. The UE sends the 
reception report when the generated random number is of a lower value than the samplePercentage value. 



9.4.4 Request Time Selection 



The MBMS receiver selects a time at which it is to issue a delivery confirmation request. The default start time for the 
reception reporting procedure is defined in clause 9.3.2. 

Back-off timing is used to spread the load of delivery confirmation requests and responses over time. 

Back-off timing is performed according to the procedure described in sub-clause 9.3.4. The offsetTime and 
randomTimePeriod used for delivery confirmation may have different values from those used for file -repair and are 
signalled separately in the reception reporting description of the associated delivery procedure description instance. 

In general, reception reporting procedures may be less time critical than file repair procedures. Thus, if a postFileRepair 
timer may expire earlier than a postReceptionReport, radio and signalling resources may be saved by using the file 
repair point-to-point PDP context (and radio bearer) activate period also for reception reporting (to remove the delay 
and signalling of multiple activations and deactivations over time) 

The default behaviour is that a UE shall stop its postReceptionReport timers which are active when a postFileRepair 
timer expires, which results in the successful initiation of point-to-point communications between UE and BM-SC. 

In some circumstances, the system bottleneck may be in the server handling of reception reporting. In this case the 
forceTimelndependence attribute may be used and set to true, (false is the default case and would be a redundant use of 
this optional attribute). 'Whtn forceTimelndependence is true the UE shall not use file repair point-to-point connections 
to send reception reporting messages. Instead it will allow the timers to expire and initiate point-to-point connections 
dedicated to reception report messaging. 

For StaR and StaR-all, session completeness - according to sub-clause 9.4.2 - shall determine the back-off timer 
initialization time. 

For RAck, the complete download session - according to sub-clause 9.4.2 - as well as completing any associated file 
repair delivery procedure shall determine the back-off timer initialization time. RAcks shall be only sent for completely 
received files. 

9.4.5 Reception Report Server Selection 

Reception report server selection is performed according to the procedure described in sub-clause 9.3.5.2. 
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9.4.6 Reception Report Message 



Once the need for reception reporting has been estabhshed, the MBMS receiver sends one or more Reception Report 
messages to the BM-SC. All Reception Report requests and responses for a particular MBMS transmission should take 
place in a single TCP session using the HTTP protocol (RFC 2616 [18]). 

The Reception Report request shall include the URI of the file for which delivery is being confirmed. URI is required to 
uniquely identify the file (resource). 

The client shall make a Reception Report request using the HTTP (RFC 2616 [18]) POST request carrying XML 
formatted metadata for each reported received content (file). An HTTP session shall be used to confirm the successful 
delivery of a single file. If more than one file were downloaded in a particular MBMS download multiple reception 
reports shall be added in a single POST request. 

Each Reception Report is formatted in XML according the following XML schema (sub-clause 9.5.3). An informative 
example of a single reception report XML object is also given (sub-clause 9.5.3.2). 

Multipart MIME (multipart/mixed) may be used to aggregate several small XML files of reception reports to a larger 
object. 

For Reception Acknowledgement (RAck) a receptionAcknowledgement element shall provide the relevant data. 

For Statistical Reporting (StaR) a statisticalReporting element shall provide the relevant data. 

For both RAck and StaR/StaR-all (mandatory): 

• For download, one or more filellRI elements shall specify the list of files which are reported. If the Content- 
MD5 value of the file is present in the FDT, it shall be provided in the Content-MD5 attribute in the reception 
report. Note, this allows unambigous identification of the files. 

For only StaR/StaR-all (all optional): 

• Each /;7ef/R/ element has an optional receptionSuccess status code attribute which defaults to "true" ("1") when 
not used. This attribute shall be used for StaR-all reports. This attribute shall not be used for StaR reports. 

• Each QoE Metrics element has a set of attributes and any number of media level QoE Metrics elements. All 
attributes are defined in sub-clause 9.5.3 and correspond to the QoE metrics listed in sub-clause 8.4.2. Individual 
metrics, both at session and at media level can be selected via SDP as described in sub-clause 8.3.2.1. 

• The sessionID attribute identifies the delivery session. If the sessionType is "download", sessionID is of the 
format source_IP_address + ":" + FLUTE_TSI. If the sessionType is "streaming", sessionID is of the format 
source_IP_address + ":" + RTP_destination_port. 

• The sessionStartTime and sessionStopTime attributes identifies the NTP time when the session was started and 
stopped. 

• The sessionType attribute defines the basic delivery method session type used = "download" II "streaming". 

• The serviceld attribute is value and format is taken from the respective userServiceDescription servicelD 
definition. 

• The cUentId attribute is unique identifier for the receiver, e.g. an MSISDN of the UE as defined in [77]. 

• The serviceURI attribute value and format is taken from the respective associatedDeliveryProcedureDescription 
serviceURI, which was selected by the UE for the current report. This attribute expresses the reception report 
server to which the reception report is addressed. 

9.4.7 Reception Report Response Message 

An HTTP response is used as the Reception Report response message. 

The HTTP header shall use a status code of 200 OK to signal successful processing of a Reception Report. Other status 
codes may be used in error cases as defined in RFC 2616 [18]. 
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9.5 XML-Schema for Associated Delivery Procedures 

9.5.1 Generic Associated Delivery Procedure Description 

Below is the formal XML syntax of associated delivery procedure description instances. Documents following this 
schema can be identifed with the MIME type "application/mbms-associated-procedure-description+xml" defined in 
Annex C.7. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns="urn: 3gpp : metadata : 2005 :MBMS : associatedProcedure" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3gpp : metadata : 2005 :MBMS : associatedProcedure" 
elementFormDefault=" qualified" > 

<xs : element name =" as sociatedProcedureDe script ion" type="associatedProcedureType"/> 
<xs : complexType name="associatedProcedureType" > 
<xs : sequence> 

<xs:element name="postFileRepair" type="basicProcedureType" minOccurs=" 0"/> 
<xs:element name="bmFileRepair" type="bmFileRepairType" minOccurs="0"/> 
<xs:element name="postReceptionReport" type="reportProcedureType" minOccurs="0"/> 
<xs : any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType > 

<xs : complexType name="basicProcedureType" > 
<xs : sequence> 

<xs:element name="serviceURI" type="xs : anyURI" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="of f setTime" type="xs lunsignedLong" use="optional"/> 
<xs : attribute name="randomTimePeriod" type="xs lunsignedLong" use="required"/> 
</xs : complexType > 
<xs : complexType name="bmFileRepairType" > 

<xs : attribute name="sessionDescriptionURI" type="xs : anyURI" use="required"/> 
</xs : complexType > 

<xs : complexType name="reportProcedureType" > 
<xs : complexContent> 

<xs : extension base="basicProcedureType" > 

<xs : attribute name="samplePercentage" type="xs : decimal" use="optional" 

default="100"/> 
<xs : attribute name="f orceTimelndependence" type="xs : boolean" use=" optional" 

default="false"/> 
<xs : attribute name="reportType" type="xs : string" use="optional"/> 
</xs : extension> 
</xs : complexContent> 
</xs : complexType> 
</xs : schema> 

"reportType" value = "RAck" | | "StaR" | | "StaR-all" 

9.5.2 Example Associated Delivery Procedure Description Instance 

Below is an example of an associated delivery procedure description for reception reporting. 

<?xml version="l . 0" encoding="UTF-8" ?> 
< as sociatedProcedureDe script ion 

xmlns =" urn: 3gpp : metadata : 2005 :MBMS : associatedProcedure" 
xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 
<postFileRepair 

offsetTime="5" 
randomTimePer iod= " 1 " > 
<serviceURI>http : //mbmsrepairO . example . com/path/repair_script</serviceURI> 
<serviceURI>http : //mbmsrepairl . example . com/pathl/repair_script</serviceURI> 
<serviceURI>http : //mbmsrepair2 . example . com/path2/repair_script</serviceURI> 
</postFileRepair> 

<bmFileRepair sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp"/> 
<postReceptionReport 

offsetTime="5" 
randomTimePer iod= "10" 
reportType= " star- all " 
samplePercentage= " 10 " 
f orceTimeIndependence= " " > 
<serviceURI>http : //mbmsreport . example . com/path/report_script</serviceURI> 
</postReceptionReport> 
</associatedProcedureDescription> 
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9.5.3 XML Syntax for a Reception Report Request 

Below is the formal XML syntax of reception report request instances. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 01/XMLSchema" 
targetNamespace="urn: 3gpp : metadata : 2008 :MBMS : receptionreport " 
xmlns="urn: 3gpp : metadata : 2 008 :MBMS : receptionreport" 
elementFormDefault= "qualified" > 

<xs : element name= "receptionReport " type= " receptionReportType " /> 
<xs rcomplexType name=" receptionReportType" > 
<xs : choice> 

<xs: element name="receptionAcknowledgement" type="rackType"/> 
<xs: element name="statisticalReport" type="starType" 

minOccur s = " " maxOccur s = " unbounded " / > 
<xs : any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> 
</xs : choice> 
</xs : complexType> 

<xs : complexType name="rackType"> 
<xs : sequence> 

<xs:element name="f ileURI" type="xs : f ileUriType" 
minOccur s = " " maxOccur s = " unbounded " / > 
</xs : sequence> 
</xs : complexType > 
<xs : complexType name="starType" > 
<xs : sequence> 

<xs:element name="f ileURI" type="f ileUriType" minOccurs="0" maxOccurs="unbounded"/> 
<xs:element name="qoeMetrics" type="qoeMetricsType" minOccurs="0" maxOccurs="l"/> 
<xs : any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs :attribute name="sessionType" type="sessionTypeType" use="optional"/> 
<xs :attribute name="serviceld" type="xs : string" use="optional"/> 
<xs : attribute name="clientld" type="xs : string" use="optional"/> 
<xs lattribute name="serviceURI" type="xs : anyURI" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType > 

<xs : simpleType name="sessionTypeType" > 
<xs : restriction base="xs : string" > 

<xs : enumeration value=" download" /> 
<xs : enumeration value=" streaming" /> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="f ileUriType" > 
<xs : simpleContent> 

<xs : extension base="xs : anyURI" > 

<xs : attribute name="receptionSuccess" type="xs : boolean" use="optional" def ault="true"/> 
<xs : attribute name=" Content -MD5" type="xs :base64Binary" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType > 

<xs : complexType name="qoeMetricsType" > 
<xs : sequence> 

<xs : element name="medialevel_qoeMetrics" type="medialevel_qoeMetricsType" 

minOccur s = " " maxOccur s = " unbounded " / > 
<xs : any namespace="##other" processContents="skip" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="totalRebuf f eringDuration" type="xs idoubleVectorType" use="optional"/> 
<xs : attribute name="numberOfRebuf f eringEvents" type="xs lunsignedLongVectorType" 

use= " optional " / > 
<xs lattribute name="initialBuff eringDuration" type="xs idouble" use="optional"/> 
<xs :attribute name="contentAccessTime" type="xs idouble" use="optional"/> 
<xs : attribute name="sessionStartTime" type="xs :unsignedLong"/> 
<xs : attribute name="sessionStopTime" type="xs :unsignedLong"/> 

<xs lattribute name="networkResourceCellId" type="xs : stringVectorType" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType > 
<xs : complexType name="medialevel_qoeMetricsType" > 

<xs : attribute name="sessionId" type="xs : string"/> 

<xs : attribute name="totalCorruptionDuration" type="xs lunsignedLongVectorType" 

use= "optional "/> 
<xs : attribute name="numberOf Corrupt ionEvents" type="xs lunsignedLongVectorType" 

use= " optional " / > 
<xs : attribute name="t" type="xs iboolean" use="optional"/> 
<xs : attribute name="totalNumberof SuccessivePacketLoss" type="xs lunsignedLongVectorType" 
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use= "optional "/> 
<xs : attribute name ="numberOf Success iveLossEvents" type="xs lunsignedLongVectorType" 

use="optional"/> 
<xs : attribute name="numberOfReceivedPackets" type="xs lunsignedLongVectorType" 

use= " optional " / > 
<xs : attribute name="f ramerateDeviation" type="xs idoubleVectorType" use="optional"/> 
<xs :attribute name="totalJitterDuration" type="xs idoubleVectorType" use="optional"/> 
<xs lattribute name="numberOf JitterEvents" type="xs lunsignedLongVectorType" use="optional"/> 
<xs lattribute name="f ramerate" type="xs idoubleVectorType" use="optional"/> 
<xs lattribute name="codecInfo" type="stringVectorType" use="optional"/> 
<xs lattribute name="codecProf ileLevel" type="stringVectorType" use="optional"/> 
<xs I attribute name="codecImageSize" type="stringVectorType" use = "optional"/> 
<xs I attribute name="averageCodecBitrate" type = "doubleVectorType" use = "optional"/> 
<xs I anyAt tribute processContents="skip"/> 

</xs I complexType> 

<xs I simpleType name="doubleVectorType" 
<xsilist itemType="xs idouble"/> 

</xs I simpleType> 

<xs I simpleType name="unsignedLongVectorType" 
<xs I list itemType = "xs iunsignedLong"/> 

</xs I simpleType> 

<xs I simpleType name="stringVectorType" 
<xsilist itemType="xs I string" /> 

</xs I simpleType> 

</xs I schema> 

9.5.3.1 Use of Specific Values 

Void 

9.5.3.2 Example XML for the Reception Report Request 

<?xml version="l . 0" encoding="UTF-8" ?> 

<receptionReport xmlns="urni 3gpp i metadata i 2008 iMBMS i receptionreport" 
xmlns ixsi="http I //www.w3 . org/2 01/XMLSchema- instance" > 
<receptionAcknowledgement> 

<f ileURI>http I //www. example . com/mbms-f iles/f ilel . 3gp</f ileURI> 
<f ileURI>http I //www. example . com/mbms-f iles/f ile2 . 3gp</f ileURI> 
<f ileURI>http I //www. example . com/mbms-f iles/f ile4 . 3gp</f ileURI> 
< /recept ionAcknowledgement > 
</receptionReport> 

A second example shows a statistical report for a streaming session. Note that the cell used during the second 
measurement period is the same cell as was used during the first period (indicated by the "=" sign). 

<?xml version="l . 0" encoding="UTF-8" ?> 

< recept ionReport xmlns="urni 3gpp i metadata i 2008 iMBMS i receptionreport" 
xmlns ixsi="http I //www. w3 .org/2 01/XMLSchema- instance" 

xsi I schemaLocation="urni 3gpp i metadata i 2008 iMBMS i receptionreport receptionreport .xsd" > 
<statisticalReport 

client Id=" client ID" 
sessionType=" streaming" 
serviceURI="bmsc . example . com" 
service Id="serviceID" > 
<qoeMetrics 

numberOfRebuf f eringEvents=" 1 0" 
initialBuf f eringDuration="3 .213" 
totalRebuf feringDuration="0 1.23 0" 
contentAccessTime="2 . 621" 
sessionStartTime=" 12 19322 514" 
sessionStopTime=" 1219322541 "> 

networkResourceCellId="240012AF134EA = 240012AF1325E" 
<medialevel_qoeMetrics 

sessionld="10 . 50. 65. 30 i 5050" 

framerateDeviation="0 . 345 0.250 0.123" 

t="false" 

numberOf SuccessiveLossEvents="5 3" 

numberOf CorruptionEvents="6 5 2" 

numberOf JitterEvents="0 1 0" 

totalCorruptionDuration="152 234 147" 

totalNumberof SuccessivePacketLoss="25 6" 

numberOfReceivedPackets="456 500 478" 

codecInfo="H263-2000/90000 = =" 

codecProf ileLevel="prof ile=0 ; level=45 = =" 
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codecImageSize="176xl44 = =" 
averageCodecBitRate="124 .5 128.0 115.1" 
totalJitterDuration="0 0.346 0"/> 
</qoeMetrics> 
</statisticalReport> 
</receptionReport> 
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Media codecs and formats 



10.1 General 

The set of media decoders that are supported by the MBMS CHent to support a particular media type are defined below. 
Speech, Audio, Video, Timed Text and Scene description media decoders are relevant for both MBMS Download and 
Streaming delivery. Other media decoders are only relevant for MBMS Download delivery. 



10.2 Speech 



If speech is supported, the AMR decoder, as specified in 3GPP TS 26.071 [48], 3GPP TS 26.090 [49], 3GPP TS 26.073 
[50] and 3GPP TS 26.107 [51], shall be supported for narrow-band speech. The AMR wideband speech decoder, 3GPP 
TS 26.171 [52], 3GPP TS 26.190 [53], 3GPP TS 26.173 [54] and 3GPP TS 26.204 [55], shall be supported when 
wideband speech working at 16 kHz sampling frequency is supported. 

10.3 Audio 

If audio is supported, then the following two audio decoders should be supported: 

• Enhanced aacPlus, as specified in 3GPP TS 26.401 [28], 3GPP TS 26.410 [29] and 3GPP TS 26.41 1 [30]. 

• Extended AMR-WB, as specified in 3GPP TS 26.290 [24], 3GPP TS 26.304 [25] and 3GPP TS 26.273 [26]. 

Specifically, based on the audio codec selection test results. Extended AMR-WB is strong for the scenarios marked with 
blue. Enhanced aacPlus is strong for the scenarios marked with orange, and both are strong for the scenarios marked 
with green colour in table 1 . 

Table 1 



Content type 
Bit rate 


IVIusic 


Speech over IVIusic 


Speech between Music 


Speech 


14 kbps mono 








— 


1 8 kbps stereo 










24 kbps stereo 










24 kbps mono 










32 kbps stereo 










48 kbps stereo 











More recent information on the performance of the codecs based on more recent versions of the codecs can be found in 
TR 26.936 [86]. 



10.4 Synthetic audio 



If synthetic audio is supported, the Scalable Polyphony MIDI (SP-MIDI) content format defined in Scalable Polyphony 
MIDI Specification [56] and the device requirements defined in Scalable Polyphony MIDI Device 5-to-24 Note Profile 
for 3GPP [57] should be supported. 

SP-MIDI content is delivered in the structure specified in Standard MIDI Files 1.0 [58], either in format or format 1. 

In addition the Mobile DLS instrument format defined in [59] and the Mobile XMF content format defined in [60] 
should be supported. 



ETSI 



3GPP TS 26.346 version 9.1 .0 Release 9 93 ETSI TS 1 26 346 V9.1 .0 (201 0-01 ) 

A PSS client supporting Mobile DLS shall meet the minimum device requirements defined in [59] in section 1.3 and the 
requirements for the common part of the synthesizer voice as defined in ISO/IEC 10646-1 [70] in section 1.2.1.2. If 
Mobile DLS is supported, wavetables encoded with the G.7 1 1 A-law codec (wFormatTag value 0x0006, as defined in 
[59]) shall also be supported. The optional group of processing blocks as defined in [59] may be supported. Mobile DLS 
resources are delivered either in the file format defined in ISO/IEC 10646-1 [70], or within Mobile XMF as defined in 
[60] . For Mobile DLS files delivered outside of Mobile XMF, the loading application should unload Mobile DLS 
instruments so that the sound bank required by the SP-MIDI profile [57] is not persistently altered by temporary 
loadings of Mobile DLS files. 

Content that pairs Mobile DLS and SP-MIDI resources is delivered in the structure specified in Mobile XMF [60]. As 
defined in [60], a Mobile XMF file shall contain one SP-MIDI SMF file and no more than one Mobile DLS file. PSS 
clients supporting Mobile XMF must not support any other resource types in the Mobile XMF file. Media handling 
behaviours for the SP-MIDI SMF and Mobile DLS resources contained within Mobile XMF are defined in [60] . 

10.5 Video 

If video is supported, H.264 (AVC) Constrained Baseline Profile Level 1.3 decoder (ITU-T Recommendation H.264I 
ISO/IEC 14496-10 [43]) without requirements on output timing conformance (annex C of [43]) should be supported. 

Note that MBMS does not offer dynamic negotiation of media codecs. To ensure the maximum level of interoperability, 
H.264 (AVC) is the only video decoder recommended for MBMS. However, it is to be noted that ITU-T 
Recommendation H.263 profile level 45 decoder (ITU-T Recommendation H.263 [45] and H.263 annex X [46]) shall 
be supported for PSS (3GPP TS 26.234 [47]) and hence may be used for MBMS User Service. 

When H.264 (AVC) is in use in the MBMS streaming delivery method, it is recommended to transmit H.264 (AVC) 
parameter sets within the SDP description of a stream (using sprop-parameter-sets MIME/SDP parameter - RFC3984 
[35]), and it is not recommended to transmit parameter sets within the RTP stream. Moreover, it is not recommended to 
reuse any parameter set identifier value that appeared previously in the SDP description or in the RTP stream. However, 
if a sequence parameter set is taken into use or updated within the RTP stream, it shall be contained at least in each IDR 
access unit and each access unit including a recovery point SEI message in which the sequence parameter set is used in 
the decoding process. If a picture parameter set is taken into use or updated within the RTP stream, it shall be contained 
at the latest in the first such access unit in each entry sequence that uses the picture parameter set in the decoding 
process, in which an entry sequence is defined as the access units between an IDR access unit or an access unit 
containing a recovery point SEI message, inclusive, and the next access unit, exclusive, in decoding order, which is 
either an IDR access unit or contains a recovery point SEI message. 

There are no requirements on output timing conformance (annex C of ITU-T Recommendation H.264 [43]) for MBMS 
clients. 

The H.264 (AVC) decoder in an MBMS client shall start decoding immediately when it receives data (even if the 
stream does not start with an IDR access unit) or alternatively no later than it receives the next IDR access unit or the 
next recovery point SEI message, whichever is earlier in decoding order. Note that when the interleaved packetization 
mode of H.264 (AVC) is in use, de -interleaving is normally done before starting the decoding process. The decoding 
process for a stream not starting with an IDR access unit shall be the same as for a valid H.264 (AVC) bitstream. 
However, the client shall be aware that such a stream may contain references to pictures not available in the decoded 
picture buffer. 



10.6 Still images 



If still images are supported, ISO/IEC JPEG [61] together with JFIF [62] decoders shall be supported. The support for 
ISO/IEC JPEG only applies to the following two modes: 

• baseline DCT, non-differential, Huffman coding, as defined in table B.l, symbol 'SOFO' in 
3GPPTS 26.273 [26]; 

• progressive DCT, non-differential, Huffman coding, as defined in table B.l, symbol 'SOF2' 
3GPPTS 26.273 [26]. 
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10.7 Bitmap graphics 

If bitmap graphics is supported, the following bitmap graphics decoders should be supported: 

• GIF87a, [63]; 

• GIF89a, [64]; 

• PNG, [65]. 

10.8 Vector graphics 

If vector graphics is supported, SVG Tiny 1.2 [66], [67] and ECMAScript [68] shall be supported. 

NOTE 1: The compression format for SVG content is GZIP [42], in accordance with the SVG specification [66]. 

NOTE 2 Content creators of SVG Tiny 1 .2 are strongly recommended to follow the content creation guidelines 
provided in annex L of 3GPP TS 26.234 [47]. 

NOTE 3: A DIMS client is capable of processing SVG Tiny 1.2 data.. 

10.9 Text 

The text decoder is intended to enable formatted text in a SMIL presentation. 
If text is supported, a MBMS client shall support 

• text formatted according to XHTML Mobile Profile [69]; 

• rendering a SMIL presentation where text is referenced with the SMIL 2.0 "text" element together with the 
SMIL 2.0 "src" attribute. 

If text is supported, the following character coding formats shall be supported: 

• UTF-8, [71]; 

• UCS-2, [70]. 

NOTE: Since both SMIL and XHTML are XML based languages it would be possible to define a SMIL plus 
XHTML profile. In contrast to the presently defined SMIL Language Profile that only contain SMIL 
modules, such a profile would also contain XHTML modules. No combined SMIL and XHTML profile is 
specified for MBMS. Rendering of such documents is out of the scope of the present document. 

10.10 Timed text 

If timed text is supported, MBMS clients shall support 3GPP TS 26.245 [72]. Timed text may be transported over RTP 
or downloaded contained in 3GP files using Basic profile. 

NOTE: When a MBMS client supports timed text it needs to be able to receive and parse 3GP files containing the 
text streams. This does not imply a requirement on MBMS clients to be able to render other continuous 
media types contained in 3GP files, e.g. AMR, if such media types are included in a presentation together 
with timed text. Audio and video are instead streamed to the client using RTP. 

10.11 3GPP file format 

An MBMS client shall support the Basic profile and the Extended presentation profile of the 3GPP file format 
3GPPTS 26.244 [32]. 
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10.12 Scene Description 

If scene description is supported, MBMS clients shall support 3GPP DIMS TS 26.142 [89]. 

1 1 IVIBIVIS IVIetadata 

11.1 The IVIBMS IVIetadata Envelope 

11.1.1 Supported Metadata Syntaxes 

The MBMS metadata syntax supports the following set of features: 

• Support of carriage of SDP descriptions, and SDP is expected to sufficiently describe at least: MBMS Streaming 
sessions and, MBMS download sessions. 

• Support for multiple metadata syntaxes, such that the delivery and use of more than one metadata syntax is 
possible. 

• Consistency control of metadata versions, between senders and receivers, independent of the transport and bearer 
use for delivery. 

• Metadata fragments are identified, versioned and time-limited (expiry described) in a metadata fragment syntax- 
independent manner (which is a consequence of the previous two features). 

1 1 .1 .2 Consistency Control and Syntax Independence 

The Metadata Envelope provides information to identify, version and expire metadata fragments. This is specified to be 
independent of metadata fragments syntax and of transport method (thus enabling the use of more than one syntaxes 
and enable delivery over more than a single transport and bearer). 

A metadata envelope may update the time validity of its metadata fragment without changing version if the metadata 
fragment itself has not changed. A newer version (higher version number) of a metadata envelope shall automatically 
expire the earlier version. If the content type (metadata fragment syntax) is recognized and valid, the UE shall use the 
new metadata fragment description. However, if the content type is not recognized or valid, the UE may maintain the 
expired version data until the newer version is correctly received. 

Service announcement senders shall increment the version by one for each subsequent transported version of a metadata 
fragment. However, a UE shall also accept versions with an increment greater than one (so that they do not fail in the 
case that an intermediate version was not successfully transported). 

1 1 .1 .3 Metadata Envelope Definition 

The attributes for a metadata envelope and their description is as follows. These attributes shall be supported: 

• metadataURI: A URI providing a unique identifier for the metadata fragment. The metadataURI attribute shall 
be present. 

• version: The version number of the associated instance of the metadata fragment. The version number should 
be initialized to one. The version number shall be increased by one whenever the metadata fragment is updated. 
The version attribute shall be present. 

• validFrom: The date and time from which the metadata fragment file is valid. The validFrom attribute may or 
not be present. If not present, the UE should assume the metadata fragment version is valid immediately. 

• validUntil: The date and time when the metadata fragment file expires. The validUntil attribute may or not be 
present. If not present the UE should assume the associated metadata fragment is valid for all time, or until it 
receives a newer metadata envelope for the same metadata fragment describing a validUntil value. 
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• contentType: The MIME type of the metadata fragment which shall be used as defined for "Content-Type" in 
RFC 2616 [18]. The contentType attribute shall be present for embedding metadata envelopes. The contentType 
attribute may be present for referencing metadata envelopes. 

The metadata envelope is instantiated using an XML structure. This XML contains a URI referencing the associated 
metadata fragment. The formal schema for the metadata envelope is defined as an XML Schema as follows. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.w3 . org/2 001/XMLSchema" 
xmlns="urn: 3gpp : metadata : 2005 :MBMS : envelope" 

elementFormDefault=" qualified" attributeFormDefault=" unqualified" 
targetNamespace="urn: 3gpp : metadata : 2005 :MBMS : envelope" > 

<xs : element name="metadataEnvelope" type="metadataEnvelopeType"/> 
<xs : complexType name="metadataEnvelopeType" > 
<xs : sequence> 

<xs:element name="item" type="metadataEnvelopeItemType" maxOccurs="unbounded" 
minOccurs= " 1 " / > 

</xs : sequence> 
</xs : complexType> 

<xs : complexType name="metadataEnvelopeItemType" > 
<xs : sequence> 

<xs: element name="metadataFragment" type="xs : string" minOccurs="0" maxOccurs="l"/> 
<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : attribute name="metadataURI" type="xs : anyURI" use=" required" /> 
<xs : attribute name= "version" type="xs :positiveInteger" use=" required" /> 
<xs : attribute name="validFrom" type="xs idateTime" use="optional"/> 
<xs : attribute name="validUntil" type="xs idateTime" use="optional"/> 
<xs : attribute name=" contentType" type="xs : string" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType > 
</xs : schema> 

The metadataFragment element shall be encapsulated in the metadata envelope for embedded metadata fragments, and 
shall not be encapsulated where the metadata fragment is not embedded. In the embedded case, the metadataFragment 
element shall contain exactly one embedded metadata fragment as specified by the metadata envelope syntax and only 
one instance of the envelope element shall be used for encapsulating envelopes. 

An embedded metadata fragment (in the metadataFragment element) shall be escaped. Generally, an embedded 
metadata fragment should be escaped by placing inside a CDATA section [31]. Everything starting after "<![CDATA[" 
string and ending at the "]]>" string would be ignored by the XML envelope parser (quotes not included). Thus, the 
embedded parts would appear as "<![CDATA[" + metadata_fragment + "]]>". In this case, the complete metadata 
envelope with embedded metadata fragment shall not violate the rules of CDATA section usage [31]. 

In case the embedded metadata fragment is an XML document and include a CDATA section , the embedded 
metadata fragment may be escaped by replacing illegal characters with their ampersand-escaped equivalents [31] 
(instead of encapsulating the whole fragment in a CDATA section). For instance "<" is an illegal character that would 
be replaced by "<". This method is useful to avoid nesting CDATA sections (which is not allowed). 

A metadata fragment which does not adhere to either of these two methods shall not be embedded in a metadata 
envelope, thus it may only be referenced from an referencing metadata envelope. 

Embedded fragments are not expected to be parsed by the metadata envelope XML parser, but decapsulated and passed 
to the relevant metadata management operation that is implementation specific (e.g. for immediate parsing, storage, 
etc.). 

11.1.4 Delivery of the Metadata Envelope 

An instance of metadata envelope shall be associated with an instance of a metadata fragment by one of two methods: 

• Embedded: The metadata fragment is embedded within the metadata envelope. 

• Referenced: The metadata fragment is referenced from the metadata envelope. 

The MBMS UE must know the MIME Type of each metadata fragment. 

In the embedded case, the envelope and fragment are, by definition, transported together and in-band of one another. In 
the referenced case, the envelope and fragment shall be transported together in-band of the same transport session. 
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MBMS Service Announcement transports shall support delivery of the metadata envelope as a discrete object (XML 
document) for the referenced case. In the referenced case, the MIME type of the metadata fragment should be provided 
by the transport protocol (e.g. as a Content-Type text string). In both cases, the MIME type of the metadata envelope 
should be provided by the transport protocol. 

The Metadata Envelope includes a reference {metadataURI) to the associated metadata fragment using the same URI as 
the fragment file is identified by in the Service Announcement. Thus, Metadata Envelope can be mapped to its 
associated metadata fragment. 

1 1 .2 MBMS User Service Description Metadata Fragment 
11 .2.1 Definition of tine IVIBIVIS User Service Bundle Description 
11.2.1.1 Initial Definition 

The root element of the MBMS User Service Bundle description is the bundleDescription element. The element is of 
the bundleDescriptionType. The bundleDescription contains one or several userServiceDescription elements and 
optionally a reference to the EEC repair stream description. 

Each userServiceDescription element shall have a unique identifier. The unique identifier shall be offered as serviceld 
attribute within the userServiceDescription element and shall be of URN format. 

The userServiceDescription elevaeni may contain one or more name elements. The intention of a name element is to 
offer a title of the user service. For each name elements, the language shall be specified according to XML datatypes 
(XML Schema Part 2 [22]). 

The userServiceDescription element may contain one or more service Language elements. Each service Language 
element represents the available languages of the user services. The language shall be specified according to XML 
datatypes (XML Schema Part 2 [22]). 

The userServiceDescription element may contain an accessPointName attribute. The accessPointName attribute is 
optional and gives an Access Point Name (APN) as defined in [77]. When this attribute is present, the MBMS UE shall 
use the given APN for MBMS UE to network interactions like File Repair and/or security registration. If this attribute is 
not present, the MBMS UE shall use a default PDP context for network interactions. 

Each userServiceDescriptionelement shall contain at least one deliveryMethod element. The deliveryMethod element 
contains the description of one delivery method. The element shall contain one reference to a session description and 
may contain references to one associated delivery procedure and/or one service protection descriptions. The session 
description is further specified in sub-clause 5.2.2.2. 

A requiredCapabilities element gives a list of features, which are required for the consumption of the related MBMS 
user service. The list of features that are currently defined is included in section 1L9. The value of the/eafMre element 
indicates the required feature. Note that the BM-SC can also determine the terminal capabilities from the terminal 
identification during the security registration. If the registering terminal does not have the required capabilities, the BM- 
SC can reject the security registration. 

The deliveryMethod element may contain a reference to an associated delivery procedure description. The description 
and configuration of associated delivery procedures is specified in sub-clause 5.2.2.3. 

The deliveryMethod element may contain a reference to a service protection description. The service protection 
description is specified in sub-clause 5.2.2.4. 

A userServiceDescription element contains zero or more accessGroup elements. An accessGroup element defines a list 
of access networks and is uniquely identified by its id attribute. An accessGroup element describes whether separate 
access systems for the same MBMS user service are used (see sub-clause 5.L5.2 of [4]) by including one or more 
accessBearer elements, each describing one of those access systems and no two describing the same. Possible 
accessBearer values are "3GPP.R6.UTRAN" and "3GPP.R6.GERAN" which indicate transport by 3GPP MBMS 
bearers according to the specification in [4]. The accessBearer value for evolved UTRAN is "3GPP.R9.E-UTRAN". 

For forward compatibility, other accessBearer values are allowed but their definition and use are out of scope of this 
specification and a 3GPP UE may silently ignore other values. 
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Each delivery Method element contains at most one accessGroupId attribute. One specific accessGroupId value maps to 
one specific accessGroup element id value. For each unique accessGroupId attribute value presented in a 
deliveryMethod element of a userServiceDescription instance, exactly one associated accessGroup element shall be 
present and the id attribute of the accessGroup element and the accessGroupId attribute shall have the same value. For 
each deliveryMethod element without an accessGroupId attribute, the UE should assume that the delivery method is 
offered through all available MBMS access systems. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn: 3GPP : metadata : 20 05 :MBMS : userServiceDescription" 
xmlns :xs="http: //www.wS . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS : userServiceDescription" elementFormDefault=" qualified" > 
<xs : element name="bundleDescription" type="bundleDescriptionType"/> 
<xs : complexType name="bundleDescriptionType" > 
<xs : sequence> 

<xs : element name="userServiceDescription" type="userServiceDescriptionType" 
maxOccur s = " unbounded " / > 

<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : attribute name="f ecDescriptionURI" type="xs : anyURI" use="optional"/> 
<xs :anyAt tribute processContents="skip"/> 
</xs : complexType> 

<xs : complexType name="userServiceDescriptionType" > 
<xs : sequence> 

<xs:element name="name" type="nameType" minOccurs=" 0" maxOccurs="unbounded"/> 
<xs:element name="serviceLanguage" type =" xs : language" minOccurs=" 0" 
maxOccur s = " unbounded " / > 

<xs: element name="requiredCapabilities" type="requirementsType" minOccurs="0" 
maxOccurs= " 1 " / > 

<xs:element name="deliveryMethod" type="deliveryMethodType" maxOccurs="unbounded"/> 
<xs:element name="accessGroup" type="accessGroupType" minOccurs=" 0" 
maxOccur s= " unbounded " / > 

<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : attribute name="serviceld" type="xs : anyURI" use=" required" /> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 

<xs : complexType name="accessGroupType" > 
<xs : sequence> 

<xs:element name="accessBearer" type="xs : string" maxOccurs="unbounded"/> 
</xs : sequence> 

<xs : attribute name="id" type="accessGroupIdType" use=" required" /> 
</xs : complexType> 

<xs : complexType name="deliveryMethodType" > 
<xs : sequence> 

<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : attribute name=" accessGroupId" type="accessGroupIdType" use="optional"/> 
<xs : attribute name="associatedProcedureDescriptionURI" type="xs : anyURI" use="optional"/> 
<xs lattribute name="protectionDescriptionURI" type="xs : anyURI" use="optional"/> 
<xs : attribute name="sessionDescriptionURI" type="xs : anyURI" use=" required" /> 
<xs :attribute name="accessPointName" type="xs : anyURI" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
<xs : complexType name="nameType" > 
<xs : simpleContent> 

<xs : extension base="xs : string" > 

<xs : attribute name="lang" type="xs : language" use="optional"/> 
</xs : extension> 
</xs : simpleContent> 
</xs : complexType> 
<xs : simpleType name="accessGroupIdType" > 

<xs : restriction base="xs monNegativelnteger" > 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="requirementsType" > 
<xs : sequence> 

<xs:element name="f eature" type="xs lunsignedlnt" minOccurs="l" maxOccurs="unbounded"/> 
</xs : sequences> 
</xs : complexType> 
</xs : schema> 
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1 1 .2.1 .2 Extensions to the User Service Bundle Description 

The MBMS Release 7 schema defined in this clause extends the MBMS Release 6 schema of clause 11.2.1.1. An 
MBMS Release 7 User Service Description fragment shall use the MBMS Release 6 and the MBMS Release 7 schema 
definitions. 

An initiationRandomization element and terminationRandomization element carries the parameters to be used by the 
MBMS UE to randomize their initiation and/or termination operations over time. If the initiationRandomization element 
is present, all MBMS UEs shall randomize the inititation time as defined by the attributes of the elements. If the 
terminationRandomization element is present, all MBMS UEs shall randomize the termination time as defined by the 
attributes of the elements. 

The initiationRandomization and/or terminationRandomization element may be part of; 

• a bundleDescription, where it applies to all services in the service bundle 

• a userServiceDescription, where it applies to all MBMS bearer services of a single service. If present, this 
overrides the element in bundleDescription 

If the initiationRandomization element is not present, the MBMS UE does not randomize the User Service Initiation 
procedure over time. The MBMS UE should then perform the operation immediately when it is triggered. 

If the terminationRandomization element is not present, the MBMS UE does not randomize the User Service 
Termination procedure over time. The MBMS UE should then perform the operation immediately when it is triggered. 

An initiationRandomization element may contain the initiationStartTime attribute, which defines the start time for the 
initiation procedure randomization period. The value of the data field represents the 32 most significant bits of a 64 bit 
Network Time Protocol (NTP) [78] time value. If the initiationStartTime attribute is not present, the MBMS UE shall 
use the reception time of the User Service Discovery / Announcement information as initiationStartTime. 

The initiationRandomization element shall contain the protectionPeriod attribute. The protectionPeriod attribute 
expresses the length of the protection period in seconds. The initiation procedure shall be randomly deferred during 
protection period. 

The initiationRandomization element shall contain the randomTime Period attribute. The randomTime Period attribute 
expresses the length of a time interval (in seconds) over which requests are deferred. The MBMS UE shall calculate a 
random time for the execution of the initiation procedure. The method provides for statistically uniform distribution 
over a relevant period of time. 

The terminationRandomization element shall contain the protectionPeriod attribute. The protectionPeriod attribute 
expresses the length of the protection period in seconds. The termination procedure execution shall be randomly 
deferred during protection period. 

The terminationRandomization element shall contain the randomTimePeriod attribute. The randomTimePeriod attribute 
expresses the length of a time interval (in seconds) over which the operations are deferred. The MBMS UE shall 
calculate a random time for the execution of the termination procedure. The method provides for statistically uniform 
distribution over a relevant period of time. 

If the MBMS UE is switched off during the termination randomization, the MBMS UE shall cancel the termination 
randomization. 

The alternativeUnicastDelivery element shall extend the list of elements of the MBMS deliveryMethod element. 
Whenever present, it shall contain at least one unicastAccessURI element. If the alternativeUnicastDelivery element is 
available then the UE shall select one of the unicastAccessURI elements included. The timeShiftingBuffer attribute may 
be used to indicate the minimal size of the time shifting buffer that will be provided for the current service by the PSS 
servers that are referenced in the list. The actual size of the timeshifting buffer of the selected server is returned in the 
SETUP response from the PSS Server. 

The serviceClass attribute, if present, shall extend the list of attributes of the MBMS Release 6 userServiceDescription 
element. The serviceClass attribute is optional and contains the service class identifier for the delivered service 
according to the syntax defined in clause E.1.2 of [90]. Note that Annex E of [90] also foresees the registration of 
service class identifiers with the Open Mobile Naming Authority. The service class identifier is similar to MIME types 
and provides an unique identity to services. A MBMS UE may determine the receiving application instance out of the 
service class identifier. 
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A user service description may belong to a group of user service descriptions, which represent alternative configurations 
of the same user service. An example is an MBMS user service that is delivered over non-MBSFN bearer with a low 
bitrate and over MBSFN bearer with a high bitrate. In such a case, the UE is only expected to consume one variant of 
the service. The UE recognizes that a set of user service descriptions apply to one user service based on the 
serviceGroup element. 

The MBMS User Service Description may include a Registration element. If present, then the UE shall send the 
registration and deregistration to the given URI. In such a case, the User Service Description fragment may not be 
complete in the service announcement. Instead, it may contain references to metadata fragments (e.g. the session 
description) that are not embedded in the service announcement. When registration is requested, the 
userServiceDescription element shall contain a Registration element that describes the requested registration procedure. 
The registrationURL indicates the URL to the server with whom the registration procedure shall be performed. In case 
more than one registrationURI is indicated, the UE shall select one randomly. The registrationThreshold is a number 
that indicates the percentage of UEs that are requested to register. The UE shall randomly select a number between 
and 100 and compare it against the threshold. In case the selected number is lower than the indicated threshold, the UE 
should perform registration. The threshold value "100" indicatess that the UE shall perform registration, which is e.g. 
necessary when the USD is not complete. 

Extensions for the User Service Description schema are defined as follows 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn: 3GPP : metadata : 2007 :MBMS : userServiceDescription" 

xmlns :xs= "http://www.w3 . org/2 1/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2007 :MBMS : userServiceDescription" 

elementFormDefault=" qualified" > 

<xs : element name="initiationRandomization" > 
<xs : complexType> 

<xs : attribute name="initiationStartTime" type="xs lunsignedlnt" use="optional"/> 
<xs : attribute name="protectionPeriod" type="xs :unsignedlnt" use="required"/> 
<xs : attribute name="randomTimePeriod" type="xs lunsignedlnt" use="required"/> 
</xs : complexType> 
</xs : element > 

<xs : element name="terminationRandomization" > 
<xs : complexType> 

<xs : attribute name="protectionPeriod" type="xs lunsignedlnt" use="required"/> 
<xs : attribute name="randomTimePeriod" type="xs lunsignedlnt" use="required"/> 
</xs : complexType> 
</xs : element > 
<xs : complexType name="serviceGroupType" > 

<xs : attribute name="groupID" type="xs : anyURI" use="required"/> 
</xs : complexType> 

<xs:element name="unicastAccessURI" type="xs : anyURI" minOccurs=" 0" maxOccurs=" unbounded" /> 
<xs lattribute name="serviceClass" type="xs : string" use="optional" > 
</xs : schema> 

The following schema defines extensions to the User Service Description introduced in Release 8: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns =" urn: 3GPP : metadata : 2008 :MBMS : userServiceDescription" 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2008 :MBMS : userServiceDescription" 

elementFormDefault = " qualified" > 

<xs : element name="alternativeAccessDelivery" > 

<xs : sequence> 

<xs:element name="unicastAccessURI" type="xs : anyURI" minOccurs="0" maxOccurs="unbounded"/> 

</xs : sequence> 

<xs :attribute name="timeShif tingBuf f er" type="xs :unsignedlnt " use="optional" def ault="0"/> 
</xs : element > 

<xs : element name="Registration" > 
<xs : complexType > 
<xs : sequence> 

<xs:element name="registrationURL" type="xs : anyURI" minOccurs="l" 
maxOccur s = " unbounded " / > 
</xs : sequence> 

<xs : attribute name=" registrationThreshold" type="xs :unsignedlnt" use="optional" 
default="100"/> 

</xs : complexType > 
</xs : element > 
</xs : schema> 
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1 1 .2.2 Example MBMS User Service Description Instances 

The following User Service Bundle Description instance is an example of a simple fragment. This fragment includes 
only the mandatory elements. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns="urn: 3GPP : metadata : 2005 :MBMS : userServiceDe script ion" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

<userServiceDe script ion serviceld="urn: 3gpp : 01012 0123hotdog" > 

<deliveryMethod sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp"/> 

</userServiceDescription> 
</bundleDe script ion> 

The following User Service Description instance is an example of a fuller fragment. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns= "urn :3GPP: metadata: 2005 :MBMS : userServiceDescription" 
xmlns :xsi="http : //www.w3 . org/2 01/XMLSchema- instance" 

f ecDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl-f ec . sdp" > 
<userServiceDescription serviceld="urn: 3gpp : 1234 567890coolcat" > 
<name lang="EN" >Welcome</name> 
<name lang="DE" >Willkommen</name> 
<name lang="FR" >Bienvenue</name> 
<name lang="FI" >Tervetuloa</name> 
<serviceLanguage>EN</serviceLanguage> 
<serviceLanguage>DE</serviceLanguage> 
<requiredCapabilities> 

<f eature>0"</f eature> 
</requiredCapabilities> 
<deliveryMethod accessGroupId="l" 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp"/> 
<deliveryMethod sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session2 . sdp" 

associatedProcedureDescriptionURI="http : //www. example. com/3gpp/mbms/procedureX.xml"/> 
<deliveryMethod sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session3 . sdp" 

associatedProcedureDescriptionURI="http : //www. example . com/3gpp/mbms/procedureY.xml"/> 
<deliveryMethod accessGroupId="2" 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session4 . sdp"/> 
<accessGroup id="l"> 

<accessBearer>3GPP .R6 .GERAN</accessBearer> 
<accessBearer>3GPP.R6 .UTRAN</accessBearer> 
</accessGroup> 
<accessGroup id="2"> 

<accessBearer>3GPP .R6 .UTRAN</accessBearer> 
</accessGroup> 
</userServiceDescription> 
</bundleDe script ion> 
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The following User Service Description instance is an example of a Release 7 fragment. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns="urn: 3GPP : metadata : 2005 :MBMS : userServiceDe script ion" 
xmlns :xsi="http : //www. w3 . org/2 1/XMLSchema- instance" 
xmlns :r7="urn: 3GPP : metadata : 2007 :MBMS : userServiceDe script ion" 
f ecDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl-f ec . sdp" > 
<userServiceDescription serviceld="urn: 3gpp :1234567890coolcat"> 
<name lang="EN" >Welcome</name> 
<name lang="DE" >Willkommen</name> 
<name lang="FR" >Bienvenue</name> 
<name lang="FI" >Tervetuloa</name> 
<serviceLanguage>EN</serviceLanguage> 
<serviceLanguage>DE</serviceLanguage> 
<deliveryMethod accessGroupId="l" 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/sessionl . sdp"/> 
<deliveryMethod sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session2 . sdp" 

associatedProcedureDescriptionURI="http : //www. example. com/3gpp/mbms/procedureX.xml"/> 
<deliveryMethod sessionDescriptionURI="http : //www. example. com/3gpp/mbms/session3 . sdp" 

associatedProcedureDescriptionURI="http : //www. example . com/3gpp/mbms/procedureY.xml"/> 
<deliveryMethod accessGroupId="2" 

sessionDescriptionURI="http : //www. example . com/3gpp/mbms/session4 . sdp"/> 
<accessGroup id="l"> 

<accessBearer>3GPP . R6 . GERAN</accessBearer> 
<accessBearer>3GPP .R6 .UTRAN</accessBearer> 
</accessGroup> 
<accessGroup id="2"> 

<accessBearer>3GPP .R6 .UTRAN</accessBearer> 
</accessGroup> 

<r7 : serviceGroup groupID="http : //www. example . com/mbms/serviceGroupl"/> 
<r7 : initiationRandomization initiationStartTime="34S8452458" protectionPeriod="600" 
randomTimePer iod= " 3 " / > 

<r7 : terminationRandomization protectionPeriod="300" randomTimePeriod="120"/> 
</userServiceDescription> 
</bundleDescription> 

The following example User Service Description instance adds an RTSP URI for alternative access to the delivery 
method. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns="urn: 3GPP : metadata : 20 05 :MBMS : userServiceDescription" 
xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" 
xmlns : r7= "urn :3GPP: metadata: 2007 :MBMS : userServiceDescription" > 
xmlns : r8="urn : 3GPP : metadata : 2007 :MBMS : userServiceDescription" > 

<userServiceDescription serviceld="urn: 3gpp : 1234 56 78 90MobileTVChannelBundleChl" 
serviceClass="urn:oma : beast : ext_bsc_3gpp : example_service : 1 . 0" > 
<deliveryMethod 
sessionDescriptionURI="http: //www. example . com/3gpp/mbms/channell . sdp"> 
<r8 :alternativeUnicastDelivery timeShiftingBuf f er="3600"> 
<r8 :unicastAccessURI>rtsp: //www. example . com/3gpp/mbms/channell_pss . sdp 
</rB :unicastAccessURI> 
</rB : alternativeUnicastDelivery> 
</deliveryMethod> 
</userServiceDescription> 
</bundleDe script ion> 

The following example User Service Description instance indicates that a registration procedure is requested for 50% of 
the UEs before the consumption of the MBMS User Service. 
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<?xml version="l . 0" encoding="UTF-8" ?> 
<bundleDescription 

xmlns= "urn :3GPP: metadata: 2005 :MBMS : userServiceDescription" 

xmlns :xsi="http : //www. w3 . org/2 1/XMLSchema- instance" 

xmlns : r7= "urn :3GPP: metadata: 2007 :MBMS : userServiceDescription" 

xmlns : r8= "urn :3GPP: metadata: 2008 :MBMS : userServiceDescription" > 

<userServiceDescription serviceld="urn: 3gpp : 12 34 5 6 78 9 0MobileTVChannelBundleChl" 
serviceClass="urn:oma : beast : ext_bsc_3gpp : example_service : 1 . 0" > 
<deliveryMethod 
sessionDescriptionURI="http: //www. example . com/3gpp/mbms/channell . sdp"> 
<rB : Registration regis trationThreshold="50"> 

<registrationURI> http : //www. example . com/ 3gpp/mbms /regi s t er.php</ regis t rat ionURI> 
</r8 :Registration> 
</deliveryMethod> 
</userServiceDe script ion> 
</bundleDe script ion> 

1 1 .3 Service Protection Description IVIetadata Fragment 
1 1 .3.1 Definition of tine Protection Description 

The security description is referenced by the protectionDescriptionURI of a dehveryMethod element. The security 
description fragment shall be identified by the MIME type "application/mbms protection-description+xml" as defined in 
Annex C.6. 

The root element of the security description is the securityDescription element. It contains three different elements, the 
keyld element identities the key(s) for each media flow, the keyManagemen element the keymanagement servers that 
the load is distributed over and the parameters in use, and the fecProtection element that configures the FEC protection 
of the point to multi-point distributed key flows. 

The keyManagement element defines the list of key management servers (i.e. BM-SC). The MBMS UE must register 
with a key management server to receive key material. A receiver shall select a key managment server following the 
same procedure defined for selecting a file repair server defined in sub-clause 9.3.5. 

The attribute uiccKeyManagement defines whether UICC based key management is required for the present MBMS 
User Service. 

The ojfsetTime and randomTimePeriod attributes define the back off behavior of the UE when requesting MSKs. This 
uses the procedure defined in sub-clause 9.3.4 where ojfsetTime specifies the offset time defined in sub-clause 9.3.4.1 
and randomTimePeriod the length of the random window in accordance with sub-clause 9.3.4.2. The units for both 
attributes are in seconds. 

The element keyld contains a list of media flows for which keys are required. For each media flow a key identifier is 
provide in addition to that media flows additional security parameters. The media flow is identified by a destination 
tuple providing an address followed by a port number separated by a "/", i.e. <IP-destination-address>/<destination- 
port>. The port number is for RTP session the RTP port number, and not RTCP's. Additional security parameters are 
srtpAuthenticationTagLength and srtpMKILength that are only applicable for RTP sessions that uses SRTP. The MSK 
element identifies the key uniquely by specifying both the keyDomainID and the MSKID as defined in sub-clause 
6.3.2.1 of 3GPP TS 33.246 [20]. The MSKID is 4 bytes long binary with byte 3 and 4 equal to 0x00, i.e. the current key 
that are base64 [82] when written into the element. The keyDomainID is a 3 byte long binary value as specified in sub- 
clause 6.3.2.1 of [20] and shall also be base64 encoded when written in the XML document. 

The attribute srtpAuthenticationTagLength defines the length of SRTP authentication tag in bytes. It has a default value 
of 10 bytes. For media flows using SRTP the attribute must be used to specify any value other than the default one. 

The attribute srtpMKILength defines the length of SRTP MKI field in bytes. The default value is 2 bytes. For media 
flows using SRTP the attribute must be used to specify any value other than the default one. 

The presence of the fecProtection element indicates that any MIKEY packet with an multicast destination IP address 
equal to any of the used destination address in the User Service Bundle Description instance's delivery methods, are 
FEC protected and encapsulated in FEC source packets, see sub-clause 8.2.2.4. The attrihxxtes fecEncodingId, 
fecInstancelD, and fecOtiExtension specify the FEC payload ID used in the source packet. All service protection 
descriptions referenced by a User Service Bundle Description instance shall use the same FEC parameters. 
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XML schema for Security Description: 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn: 3GPP : metadata : 2005 :MBMS : securityDe script ion" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS : securityDescription" elementFormDefault=" qualified" > 
<xs : element name=" securityDescription" type="securityDescriptionType"/> 
<xs : complexType name="securityDescriptionType" > 
<xs : sequence> 

<xs:element name="keyManagement" type="keyManagementType" minOccurs=" 0"/> 
<xs:element name="keyld" type="keyIdType" maxOccurs="unbounded"/> 
<xs:element name="f ecProtection" type="f ecProtectionType" minOccurs=" 0"/> 
<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 

<xs : complexType name="keyManagementType" > 
<xs : sequence> 

<xs:element name="serverURI" type="xs : anyURI" maxOccurs="unbounded"/> 

<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" processContents="lax"/> 
</xs : sequence> 

<xs : attribute name="of f setTime" type="xs :unsignedLong" use="optional" def ault="0"/> 
<xs :attribute name="randomTimePeriod" type="xs :unsignedLong" use="optional" def ault="0"/> 
<xs : attribute name="uiccKeyManagement" type="xs : boolean" use= "optional" def ault=" true" /> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 

<xs : complexType name="keyIdType" > 
<xs : sequence> 

<xs: element name="mediaFlow" maxOccurs="unbounded" > 
<xs : complexType > 
<xs : sequence> 

<xs: element name="MSK" type="MSKType" maxOccurs="l"/> 
</xs : sequence> 

<xs : attribute name="f lowID" type="xs : string" use="required"/> 
<xs : attribute name="srtpAuthenticationTagLength" type = "xs monNegativelnteger" 

use=" optional" def ault="10"/> 
<xs : attribute name="srtpMKILength" type="xs monNegativelnteger" use=" optional" 

default="2"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element > 
</xs : sequence> 
</xs : complexType > 
<xs : complexType name="f ecProtectionType" > 

<xs : attribute name="f ecEncodingId" type="xs lunsignedLong" use="optional" def ault="0"/> 
<xs : attribute name="f eclnstanceld" type="xs lunsignedLong" use="optional"/> 
<xs : attribute name="f ecOtiExtension" type="xs : string" use="optional"/> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
<xs : complexType name="MSKType" > 
<xs : sequence> 

<xs:element name="keyDomainID" type="xs :base64Binary" minOccurs="l" maxOccurs="l"/> 
<xs:element name="MSKID" type="MSKIDType" minOccurs="l" maxOccurs="l"/> 
</xs : sequence > 
</xs : complexType > 
<xs : simpleType name="MSKIDType" > 

<xs : restriction base="xs :base64Binary" > 

<xs : length value="4"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 

1 1 .3.2 Example of a Security Description: 

<?xml version="l . 0" encoding="UTF-8" ?> 
< securityDescription 

xmlns =" urn: 3GPP imetadata : 2005 :MBMS : securityDescription" 
xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 
<keyManagement 

offsetTime="5" 
randomTimePeriod= " 10 " 
uiccKeyManagement="true" > 

<serverURI>http : //register .operator .umts/</serverURI> 
<serverURI>http : //register2 .operator .umts/</serverURI> 
< / keyManagement > 
<keyld> 

<mediaFlow flowID="224 . 1.2. 3/4002 "> 
<MSK> 
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<keyDomainID>aMoM</keyDomainID> 
<MSKID>aMoAAA==</MSKID> 
</MSK> 
</mediaFlow> 

<mediaFlow f lowID="224 . 1 .2 . 3/4004" srtpAuthenticationTagLength="4 " > 
<MSK> 

<keyDomainID>GM8M</keyDomainID> 
<MSKID>aMkAAA==</MSKID> 
</MSK> 
</mediaFlow> 
</keyId> 
<fecProt action 

f ecEncodingId= " 1 " 
f eclnstanceld= " " 

fecOtiExtension="lSCxWEMNe3 97m24SwgyRhg=="/> 
</securityDescription> 

1 1 .4 Service Protection Registration Format 

11.4.1 Data Format 

The below XML schema defines a format used to register to the keymanagement servers according to the procedure in 
TS 33.246. The MIME type for this format is defined in appendix C.9. The servicelD element identifies the service 
uniquely and is the same servicelD used in the userServiceDescription format defined in sub-clause 11. 2.1. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www.wS . org/2 001/XMLSchema" 

targetNamespace="urn: 3GPP : metadata :2 005 :MBMS : securityRegistration" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsSecurityRegister" > 
<xs : annotation> 

<xs :documentation>MBMS Security Registration according to TS 33 . 246</xs :documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="serviceID" type="xs : anyURI" maxOccurs="unbounded" minOccurs="l"/> 
<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded" 
processContents="lax"/> 
</xs : sequence > 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element > 
</xs : schema> 

11.4.2 Example 

The below example is used to register to a service identifed by the servicelD " 
urn:3gpp:mbms:example:serivce;identification:123456789abcdef". 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mbmsSecurityRegister xmlns="urn: 3GPP : metadata : 20 05 :MBMS : securityRegistration" 

xmlns :xsi="http : //www.w3 . org/2 1/XMLSchema- instance" > 

<serviceID>urn: 3gpp :mbms : example : serivce : identification: 12 34 5 6 78 9abcdef </serviceID> 
</mbmsSecurityRegister> 

1 1 .5 Service Protection De-Registration Format 
11.5.1 Data Format 

This format is used to de -register from the keymanagement server(s) according to the procedure in TS 33.246. The 
MIME type for this format is defined in appendix C.IO. The servicelD element is defined exactly as in sub-clause 
11.4.1. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns :xs="http : //www. w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS : securityDeregistration" 

elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 

<xs : element name="mbmsSecurityDeregister" > 
<xs : annotation> 
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<xs :documentation>MBMS Security Deregistration according to TS 33 . 246</xs :documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="serviceID" type="xs ranyURI" maxOccurs= "unbounded" minOccurs="l"/> 
<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded" 
processContents="lax"/> 
</xs : sequence> 
<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element> 
</xs : schema> 

11.5.2 Example 

The below example is used to de -register from the services identifed by the servicelD " 
urn:3gpp:mbms:example:serivce:identification:123456789abcdef". 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mbmsSecurityDeregister xmlns="urn: 3GPP : metadata : 2005 :MBMS : securityDeregistration" 

xmlns :xsi="http : //www. w3 . org/2 01/XMLSchema- instance" > 

< servicelD >urn: 3gpp :mbms : example : serivce : identification: 12 34 5 6 78 9abcdef </serviceID> 
</mbmsSecurityDeregister> 

1 1 .6 Service Protection IVISK Request Format 

11.6.1 Data Format 

This format is used to request from the keymanagement server(s) the delivery of one or more MSK identities as defined 
in sub-clause 11.3.1. The MIME type for this format is defined in appendix C.8. 

<?xml version="l . 0" encoding="UTF-8" ?> 
<xs : schema 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

xmlns="urn: 3GPP : metadata : 2005 :MBMS imskRequest" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS imskRequest" 

elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : element name="mbmsMSKRequest" > 
<xs : annotation> 

<xs : documentation> 

MBMS MSK Request as defined by 3GPP TS 2S.34S and 3GPP TS 33.246 
</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="MSK" type="MSKType" minOccurs="l" maxOccurs="unbounded"/> 
</xs : sequence > 

<xs : anyAt tribute processContents="skip"/> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="MSKType" > 
<xs : sequence> 

<xs:element name="keyDomainID" type="xs :base64Binary" minOccurs="l" maxOccurs="l"/> 
<xs:element name="MSKID" type="MSKIDType" minOccurs="l" maxOccurs="l"/> 
</xs : sequence> 
</xs : complexType > 
<xs : simpleType name="MSKIDType" > 

<xs : restriction base="xs :base64Binary" > 

<xs : length value="4"/> 
</xs : restriction> 
</xs : simpleType> 
</xs : schema> 

11.6.2 Example 

The below example is used to request a single MSK with keyDomainID "uHCd" and a MSK ID part "aMkAAA==". 

<?xml version="l . 0" encoding="UTF-8" ?> 
<mbmsMSKRequest 

xmlns :xsi="http : //www. w3 .org/2 01/XMLSchema- instance" 
xmlns= "urn : 3GPP : metadata : 2 5 : MBMS : mskRequest " > 
<MSK> 
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<keyDomainID>uHCd</keyDomainID> 
<MSKID>aMkAAA==</MSKID> 
</MSK> 
</mbmsMSKRequest> 

1 1 .7 Service Protection Registration and De-Registration 
Response Format 

11.7.1 Data Format 

This format is used in the response of the keymanagement server(s) to a Service Protection Registration or De- 
Registration message. Service Protection Registration message format is defined in clause 1 1.4 and the Service 
Protection De-Registration message format in clause 11.5. The format of the response codes are defined in 3GPP 
TS 33.246 [20]. The MIME Media type for this format is defined in appendix C.13. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<xs : schema xmlns="urn: 3GPP : metadata : 2 005 iMBMS : securityRegistrationResponse" 
xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2 005 :MBMS : securityRegistrationResponse" 
elementFormDefault=" qualified" attributeFormDefault=" unqualified" > 
<xs : element name="mbmsSecurityRegisterResponse" > 
<xs : annotation> 

<xs :documentation>MBMS Security Registration Response according to TS 
33 . 246</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name=" Response" type="ResponseType" maxOccurs= "unbounded" /> 
<xs : any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="ResponseType" > 
<xs : sequence> 

<xs:element name="serviceID" type="xs : anyURI"/> 
<xs:element name="ResponseCode" type="xs : string"/> 

<xs : any namespace="##other" processContents="lax" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 



11.7.2 Example 

<?xml version="l . 0" encoding="UTF-8" ?> 

<mbmsSecurityRegisterResponse xmlns="urn: 3GPP : metadata : 2005 :MBMS : securityRegistrationResponse" 
xmlns :xsi="http : //www. w3 .org/2 01/XMLSchema- instance" 

xsi : schemaLocation="urn: 3GPP : metadata : 2005 :MBMS : securityRegistrationResponse" > 
<Response> 

<serviceID>urn: 3gpp :mbms : example : service : identification: 123456789abcdef </serviceID> 
<ResponseCode>2 OK</ResponseCode> 
</Response> 
<Response> 

<serviceID>urn: 3gpp :mbms : example : service : identification: f edcba98 76 54 321</serviceID> 
<ResponseCode>2 OK</ResponseCode> 
</Response> 
</mbmsSecurityRegisterResponse> 

1 1 .8 Service Protection IVISK Response Format 
11.8.1 Data Format 

This format is used in the response of the keymanagement server(s) to an MSK Request message. The MSK Request 
message format is defined in clause 11.6. The format of the response codes are defined in 3GPPTS 33.246 [20]. The 
MIME Media type for this format is defined in appendix C. 12. 

<?xml version="l . 0" encoding="UTF-8" ?> 
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<xs : schema xmlns="urn: 3GPP : metadata : 2005 :MBMS imskResponse" 

xmlns :xs="http: //www.w3 . org/2 01/XMLSchema" 

targetNamespace="urn: 3GPP : metadata : 2005 :MBMS imskResponse" elementFormDefault=" qualified" 

attributeFormDefault=" unqualified" > 

<xs : element name="mbmsMSKResponse" > 
<xs : annotation> 

<xs :documentation>MBMS Security MSK Request Response according to TS 
33 . 246</xs : documentation> 
</xs : annotation> 
<xs : complexType> 
<xs : sequence> 

<xs:element name="Response" type="ResponseType" maxOccurs="unbounded"/> 
<xs : any namespace="##other" minOccurs=" 0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : element > 

<xs : complexType name="MSKType"> 
<xs : sequence> 

<xs:element name="keyDomainID" type="xs :base64Binary"/> 
<xs:element name="MSKID" type="MSKIDType"/> 
</xs : sequence> 
</xs : complexType> 
<xs : simpleType name="MSKIDType" > 

<xs : restriction base="xs :base64Binary" > 

<xs : length value="4"/> 
</xs : restriction> 
</xs : simpleType> 

<xs : complexType name="ResponseType" > 
<xs : sequence> 

<xs:element name="MSK" type="MSKType"/> 
<xs: element name="ResponseCode" type="xs : string"/> 

<xs : any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> 
</xs : sequence> 
</xs : complexType> 
</xs : schema> 



11.8.2 Example 



<?xml version="l . 0" encoding="UTF-8" ?> 

<mbmsMSKResponse xmlns = " urn : 3GPP : metadata : 2 5 : MBMS : mskResponse " 
xmlns :xsi="http : //www.w3 .org/2 01/XMLSchema- instance" 
xsi : schemaLocation="urn: 3GPP : metadata : 2005 :MBMS imskResponse" > 
<Response> 
<MSK> 

<keyDomainID>uHCd</keyDomainID> 
<MSKID>aMkAAA==</MSKID> 
</MSK> 

<ResponseCode>2 OK</ResponseCode> 
</Response> 
<Response> 
<MSK> 

<keyDomainID>uHCd</keyDomainID> 
<MSKID>JMtEAA==</MSKID> 
</MSK> 

<ResponseCode>2 OK</ResponseCode> 
</Response> 
</mbmsMSKResponse> 



1 1 .9 MBMS Feature Requirements 

MBMS features enable the BM-SC to signal to the UE the set of capabilities that are required for the consumption of 
the MBMS user service. The required capability list is indicated in the MBMS User Service Description of the 
corresponding MBMS user service as defined in section 1 1.2.1. 

The MBMS UE shall not attempt to receive the service if it detects that at least one required capability, indicated in the 
USD, is not supported or not understood. The introduction of new features is possible and assumes that unidentified 
features shall be interpreted by the UE as a requirement that cannot be fulfilled. 



The following list of features is currently identified: 
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Table 2 - MBMS Feature Requirement List 



Service Capability 


References 


Recognized Feature Values 
(Integer) 


Speech 


as defined in clause 10.2 





AMR-WB 


as defined in clause 10.2 


1 


Enhanced aacPlus 


as defined in clause 10.3 


2 


Extended AMR-WB 


as defined in clause 10.3 


3 


Synthetic audio 


as defined in clause 10.4 


4 


H.263 


as mentioned in clause 10.5 


5 


H.264 Constrained Baseline Profile 
Level 1 b 


as defined in clause 10.5 (of Release 
6) 


6 


Still images 


as defined in clause 10.6 


7 


Bitmap graphics 


as defined in clause 10.7 


8 


Vector graphics 


as defined in clause 10.8 


9 


Text 


as defined in clause 10.9 


10 


Timed text 


as defined in clause 10.10 


11 


3GPP file format 


as defined in clause 10.11 


12 


H.264 Constrained Baseline Profile 
Level 1 .2 


as defined in clause 10.5 (of Release 

7) 


13 


Scene Description 


as defined in clause 10.12 


14 


MBSFN mode in UTRAN 


as defined in 3GPP TS 25.346 (of 
Release 7) 


15 


H.264 Constrained Baseline Profile 
Level 1 .3 


as defined in clause 10.5 (of Release 
9) 


16 



The list of features may be extended in the future. 



£75/ 



3GPP TS 26.346 version 9.1.0 Release 9 



110 



ETSI TS 126 346 V9.1.0 (2010-01) 



Annex A (normative): 
FLUTE Support Requirements 



This clause provides a table representation of the requirement levels for different features in FLUTE. Table A. 1 
includes requirements for an MBMS client and an MBMS server for FLUTE support as well as the requirements for a 
FLUTE client and a FLUTE server according to the FLUTE protocol (RFC 3926 [9]). The terms used in table A.l are 
described underneath. 

Table A.1 : Overview of the FLUTE support requirements in IVIBMS servers and clients 





FLUTE Client 

support requirement 

as per [9] 


MBMS FLUTE Client 

support requirement 

as per present 

document 


FLUTE Server use 

requirement as per 

[9] 


MBMS FLUTE Server 

use requirement as 

per present 

document 


FLUTE Blocking 
Algorithm 


Required 


Required 


Strongly 
recommended 


Required 


Symbol Encoding 
Algorithm 


Compact No-Code 
algorithm required. 

Other FEC building 

blocks are undefined 

optional plug-ins. 


Compact No-Code 
algorithm required. 

MBMS Forward Error 
Correction required 


Compact No-Code 

algorithm is the default 

option. 

Other FEC building 

blocks are undefined 

optional plug-ins. 


Compact No-Code 

algorithm is the default 

option. 

MBMS Forward Error 
Correction. 


Congestion Control 
Building Block (CCBB) 
/ Algorithm 


Congestion Control 

building blocks 

undefined. 


Single channel 
support required 


Single channel without 

additional CCBB given 

for the controlled 

network scenario. 


Single channel 
support required 


Content Encoding for 
FDT Instances 


Optional 


Optional 


Optional 


Shall not be used 


Content Encoding for 
any other file than 
FDT Instances 


Optional 


Required 


Optional 


Optional 


A flag active (header) 


Required 


Required 


Optional 


Not recommended to 
use 


B flag active (header) 


Required 


Required 


Optional 


Not recommended to 
use 


T flag active and SCT 
field (header) 


Optional 


Optional 


Optional 


Set to zero 


R flag active and ERT 
field (header) 


Optional 


Optional 


Optional 


Set to zero 


Content-Location 
attribute (FDT) 


Required 


Required 


Required 


Required 


TOI (FDT) 


Required 


Required 


Required 


Required 


FDT Expires attribute 
(FDT) 


Required 


Required 


Required 


Required 


Complete attribute 
(FDT) 


Required 


Required 


Optional 


Optional 


FEC-OTI-IVIaximum- 
Source-Block-Length 


Required 


Required 


Required 


Required 


FEC-OTI-Encoding- 
Symbol-Length 


Required 


Required 


Required 


Required 


FEC-OTI-Max- 

Number-of-Encoding- 

Symbols. 


Required 


Required 


Required 


Required 


FEC-OTI-FEC- 
Instance-ID 


Required 


Optional 


Required 


Optional 


FEC-OTI-Scheme- 
Specific-lnfo 


n/a 


Required 


n/a 


Required if MBMS 
FEC used 
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The following are descriptions of the above terms: 

Blocking algorithm: The blocking algorithms is used for the fragmentation of files. It calculates the source 
blocks from the source files. 

Symbol Encoding algorithm: The symbol encoding algorithm is used for the fragmentation of files. It 
calculates encoding symbols from source blocks for Compact No-Code FEC. It may also be used for other FEC 
schemes. 

Congestion Control Building Block: A building block used to limit congestion by using congestion feedback, 
rate regulation and receiver controls (RFC 3048 [17]). 

Content Encoding for FDT Instances: FDT Instance may be content encoded for more efficient transport, 
e.g. using GZIP. 

Content Encoding for any other file than FDT Instances: Files may be content encoded for more efficient 
transport, e.g. using GZIP. 

A flag: The Close Session flag for indicating the end of a session to the receiver in the ALC/LCT header. 

B flag: The Close Object flag is for indicating the end of an object to the receiver in the ALC/LCT header. 

T flag: The T flag is used to indicate the use of the optional "Sender Current Time (SCT)" field (when T=l) in 
the ALC/LCT header. 

R flag: The R flag is used to indicate the use of the optional "Expected Residual Time (ERT) field in the 
ALC/LCT header. 

Content Location attribute: This attribute provides a URI for the location where a certain piece of content (or 
file) being transmitted in a FLUTE session is located. 

Transport Object Identifier (TOI): The TOI uniquely identifies the object within the session from which the 
data in the packet was generated. 

FDT Expires attribute: Indicates to the receiver the time until which the information in the FDT is valid. 

Complete attribute: This may be used to signal that the given FDT Instance is the last FDT Instance to be 
expected on this file delivery session. 

FEC-OTI-Maximum-Source-Block-Length: This parameter indicates the maximum number of source 
symbols per source block. 

FEC-OTI-Encoding-Symbol-Length: This parameter indicates the length of the Encoding Symbol in bytes. 

FEC-OTI-Max-Number-of-Encoding-Symbols: This parameter indicates the maximum number of Encoding 
Symbols that can be generated for a source block. 

FEC-OTI-FEC-Instance-ID: This field is used to indicate the FEC Instance ID, if a FEC scheme is used. 

FEC-OTI-Scheme-Specific-Info: Carries Object Transmission Information which is specific to the FEC scheme 
in use. 
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Annex B (normative): 
FEC encoder specification 



This Annex specifies the systematic Raptor forward error correction code and its appHcation to MBMS [7]. Raptor is a 
fountain code, i.e., as many encoding symbols as needed can be generated by the encoder on-the-fly from the source 
symbols of a block. The decoder is able to recover the source block from any set of encoding symbols only slightly 
more in number than the number of source symbols. 

The code described in this document is a Systematic code, that is, the original source symbols are sent unmodified from 
sender to receiver, as well as a number of repair symbols. 



B.1 Definitions, Symbols and Abbreviations 
B.1.1 Definitions 

For the purposes of this Annex, the following terms and definitions apply. 

Source block: a block of K source symbols which are considered together for Raptor encoding purposes. 

Source symbol: the smallest unit of data used during the encoding process. All source symbols within a source block 
have the same size. 

Encoding symbol: a symbol that is included in a data packet. The encoding symbols consist of the source symbols and 
the repair symbols. Repair symbols generated from a source block have the same size as the source symbols of that 
source block. 

Systematic code: a code in which the source symbols are included as part of the encoding symbols sent for a source 
block. 

Repair symbol: the encoding symbols sent for a source block that are not the source symbols. The repair symbols are 
generated based on the source symbols. 

Intermediate symbols: symbols generated from the source symbols using an inverse encoding process . The repair 
symbols are then generated directly from the intermediate symbols. The encoding symbols do not include the 
intermediate symbols, i.e., intermediate symbols are not included in data packets. 

Symbol: a unit of data. The size, in bytes, of a symbol is known as the symbol size. 

Encoding symbol group: a group of encoding symbols that are sent together, i.e., within the same packet whose 
relationship to the source symbols can be derived from a single Encoding Symbol ID. 

Encoding Symbol ID: information that defines the relationship between the symbols of an encoding symbol group and 
the source symbols. 

Encoding packet: data packets that contain encoding symbols 

Sub-block: a source block is sometime broken into sub-blocks, each of which is sufficiently small to be decoded in 
working memory. For a source block consisting of /T source symbols, each sub-block consists of /T sub-symbols, each 
symbol of the source block being composed of one sub-symbol from each sub-block. 

Sub-symbol: part of a symbol. Each source symbol is composed of as many sub-symbols as there are sub-blocks in the 
source block. 

Source packet: data packets that contain source symbols. 

Repair packet: data packets that contain repair symbols. 
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B.1.2 Symbols 

i, j, X, h, a, b, d, v, m represent positive integers 

ceil(x) denotes the smallest positive integer which is greater than or equal to x 

choose(/j) denotes the number of ways j objects can be chosen from among / objects without repetition 

floor(x) denotes the largest positive integer which is less than or equal to x 

i%j denotes ! modulo y 

X '^ Y denotes, for equal-length bit strings X and Y, the bitwise exclusive -or of X and Y 

A denote a symbol alignment parameter. Symbol and sub-symbol sizes are restricted to be multiples of A. 

A^ denotes the transposed matrix of matrix A 

A"' denotes the inverse matrix of matrix A 

K denotes the number of symbols in a single source block 

Kmax denotes the maximum number of source symbols that can be in a single source block. Set to 8192. 

L denotes the number of pre-coding symbols for a single source block 

S denotes the number of LDPC symbols for a single source block 

H denotes the number of Half symbols for a single source block 

C denotes an array of intermediate symbols, C[0], C[l], C[2],..., C[L-1] 

C denotes an array of source symbols, C'[0], C'[l], C'[2],..., C'[/r-l] 

X a non-negative integer value 

Vo, Vi two arrays of 4-byte integers, yo[0], Vo[l],..., VoPSS] and yi[0], yi[l ],..., ViPSS] 

Rand[X, /, m] a pseudo-random number generator 

Deg[v] a degree generator 

LTEnc[/r, C ,(d, a, b)] a LT encoding symbol generator 

Trip[7C X] a triple generator function 

G the number of symbols within an encoding symbol group 

A^ the number of sub -blocks within a source block 

T the symbol size in bytes. If the source block is partitioned into sub-blocks, then T = T'-N. 

T' the sub-symbol size, in bytes. If the source block is not partitioned into sub-blocks then T' is not 

relevant. 

F the file size, for file download, in bytes 

/ the sub-block size in bytes 

P for file download, the payload size of each packet, in bytes, that is used in the recommended derivation of 

the file download transport parameters. For streaming, the payload size of each repair packet, in bytes, 
that is used in the recommended derivation of the streaming transport parameters. 

Q Q = 65521, i.e., Q is the largest prime smaller than 2"* 

Z the number of source blocks, for file download 

J(K) the systematic index associated with K 
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G 



denotes any generator matrix 
denotes the SxS identity matrix 
denotes the SxH zero matrix 



B.1.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



ESI 

LDPC 

LT 

SBN 

SBL 



Encoding Symbol ID 

Low Density Parity Check 

Luby Transform 

Source Block Number 

Source Block Length (in units of symbols) 



B.2 Overview 



The Raptor forward error correction code can be applied to both the MBMS file delivery and MBMS streaming 
applications described in the main body of this document. Raptor code aspects which are specific to each of these 
applications are discussed in sub-clauses B.3 and B.4 of this document. 

The principle component of the systematic Raptor code is the basic encoder described in sub-clause B.5. First, it is 
described how to derive values for a set of intermediate symbols from the original source symbols such that knowledge 
of the intermediate symbols is sufficient to reconstruct the source symbols. Secondly, the encoder produces repair 
symbols which are each the exclusive OR of a number of the intermediate symbols. The encoding symbols are the 
combination of the source and repair symbols. The repair symbols are produced in such a way that the intermediate 
symbols and therefore also the source symbols can be recovered from any sufficiently large set of encoding symbols. 

This document defines the systematic Raptor code encoder. A number of possible decoding algorithms are possible. An 
efficient decoding algorithm is provided in [91] section 5.5. 

The construction of the intermediate and repair symbols is based in part on a pseudo-random number generator 
described in sub-clause B.5. This generator is based on a fixed set of 512 random numbers which must be available to 
both sender and receiver. These are provided in sub-clause B.7. 

Finally, the construction of the intermediate symbols from the source symbols is governed by a 'systematic index', 
values of which are provided in sub-clause B.6 for source block sizes from 4 source symbols to Kmax =8192 source 
symbols. 
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B.3 File download 

B.3.1 Void 

B.3.2 Void 

B.3.3 Void 

B.3. 4 Example parameters 

B.3. 4.1 Parameter derivation algoritinm 

This sub-clause provides recommendations for the derivation of the four transport parameters, A, T, Z and A^. This 
recommendation is based on the following input parameters: 

F the file size, in bytes 

W a target on the sub-block size, in bytes 

P the maximum packet payload size, in bytes, which is assumed to be a multiple of A 

- A the symbol alignment factor, in bytes 

Kmax the maximum number of source symbols per source block. 

Kmin a minimum target on the number of symbols per source block 

Gmax a maximum target number of symbols per packet 

Based on the above inputs, the transport parameters T, Z and A^ are calculated as follows; 

Let, 

G = min{ceil(P -KminIF), PI A, Gmax) - the approximate number of symbols per packet 

T = floor(P/(A-G))-A 

K, = ceil(/7T) - the total number of symbols in the file 

Z = ceiliK, /Kmax) 

N= min{ceil(ceil( K,/Z)-T/W), T/A] 

The values of G and A^ derived above should be considered as lower bounds. It may be advantageous to increase these 
values, for example to the nearest power of two. In particular, the above algorithm does not guarantee that the symbol 
size, T, divides the maximum packet size, P, and so it may not be possible to use the packets of size exactly P. If, 
instead, G is chosen to be a value which divides P/A, then the symbol size, T, will be a divisor of P and packets of size 
P can be used. 

Recommended settings for the input parameters, W, A, Kmin and Gmax ^e as follows: 

W = 256 KB A = 4 Kmin = 1024 Gmax = 10 

B. 3.4.2 Examples 

The above algorithm leads to transport parameters as shown in Table B.3. 4. 2-1 below, assuming the recommended 
values for W, A, Kmin and Gmax and P = 5 12: 
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Table B.3.4.2-1 



File size f G ^^;^^°^ G*T K, 



Source 
blocks 



Sub- 
blocks A^ 



K, 



Ks 



T,A TsA 



100 KB 



1,000 KB 1 



3,000 KB 1 



84 504 1 ,220 



100 KB 8 64 512 1,600 

300 KB 2 256 512 1,200 



512 512 2,000 



512 512 6,000 



10,000 KB 1 512 512 20,000 



1 

2 

5 

12 

14 



1,220 ^ 220 ^"^ ^"^ 

1,600 1,600 N/A N/A 

1,200 1,200 128 128 

2,000 2,000 104 100 

6,000 6,000 44 40 



6,666 6,667 



40 



36 



B.4 Streaming 

B.4.1 Source block construction 

A source block is constructed by the transport protocol, for example as defined in this document, making use of the 
Systematic Raptor Forward Error Correction code. The symbol size, T, to be used for source block construction and 
the repair symbol construction are provided by the transport protocol. The parameter T shall be set so that the number of 
source symbols in any source block is at most Kmax- 

Recommended parameters are presented in sub-clause B.4 .4. 

B.4. 2 Encoding packet construction 

As described in sub-clause B.4. 3., each repair packet contains the following information: 

- Source Block Number (SBN) 

- Encoding Symbol ID (ESI) 

Source Block Length (SBL) 

repair symbol(s) 

The number of repair symbols contained within a repair packet is computed from the packet length. The ESI values 
placed into the repair packets and the repair symbol triples used to generate the repair symbols are computed as 
described in sub-clause B. 3.2.2. 



B.4. 3 Transport 



This sub-clause describes the information exchange between the Raptor encoder/decoder and any transport protocol 
making use of Raptor forward error correction for streaming. 

The Raptor encoder for streaming requires the following information from the transport protocol for each source block: 

The symbol size, T, in bytes 
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The number of symbols in the source block, K 

- The Source Block Number (SBN) 

The source symbols to be encoded, TTT bytes 

The Raptor encoder supplies the transport protocol with encoding packet information consisting, for each repair packet, 
of: 

- Source Block Number (SBN) 
Encoding Symbol ID (ESI) 
Source Block Length (SBL) 
repair symbol(s) 

The transport protocol shall communicate this information transparently to the Raptor decoder. 
A suitable transport protocol is defined in this specification. 

B.4.4 Example parameters 
B.4.4.1 Parameter derivation algoritinm 

This sub-clause provides recommendations for the derivation of the transport parameter T. This recommendation is 
based on the following input parameters: 

B the maximum source block size, in bytes 

P the maximum repair packet payload size, in bytes, which is a multiple of A 

- A the symbol alignment factor, in bytes 

KuAx the maximum number of source symbols per source block. 

Kmin a minimum target on the number of symbols per source block 

GuAx a maximum target number of symbols per repair packet 

A requirement on these inputs is that ceil(B/P) < K^ax- Based on the above inputs, the transport parameter T is 
calculated as follows: 

Let, 

G = mm{cdA{P-KMmlB), PI A, Gmax) - the approximate number of symbols per packet 

r=floor(P/(A-G))-A 

The value of T derived above should be considered as a guide to the actual value of T used. It may be advantageous to 
ensure that T divides into P, or it may be advantageous to set the value of T smaller to minimize wastage when full size 
repair symbols are used to recover partial source symbols at the end of lost source packets (as long as the maximum 
number of source symbols in a source block does not exceed Kmax)- Furthermore, the choice of T may depend on the 
source packet size distribution, e.g., if all source packets are the same size then it is advantageous to choose T so that 
the actual payload size of a repair packet P', where P' is a multiple of T, is equal to (or as few bytes as possible larger 
than) the number of bytes each source packet occupies in the source block. 

Recommended settings for the input parameters. A, Kmin and Gmax are as follows: 

A = 4 Km,n= 1024 Gmax =10 
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B.4.4.2 Examples 



The above algorithm leads to transport parameters as shown in Table B. 4.4.2-1 below, assuming the recommended 
values for A, Kmin and Gmax and P = 5 12: 

Table B.4.4.2-1 



Max source block size B 


G 


Symbol size T 


GT 


40 KB 


10 


48 


480 


160 KB 


4 


128 


512 


640 KB 


1 


512 


512 



B.5 Systematic Raptor encoder 
B.5.1 Encoding overview 

The systematic Raptor encoder is used to generate repair symbols from a source block that consists of K source 
symbols. 

Symbols are the fundamental data units of the encoding and decoding process. For each source block (sub-block) all 
symbols (sub-symbols) are the same size. The atomic operation performed on symbols (sub-symbols) for both 
encoding and decoding is the exclusive -or operation. 

Let C'[0],..., C'[/r-l] denote the TT source symbols. 

Let C[0],..., C[L-1] denote L intermediate symbols. 

The first step of encoding is to generate a number, L> K,of intermediate symbols from the K source symbols. In this 
step, /T source triples {d{Qi\, fl[0], ^[0]), ..., {d{K-l}, aYK-l}, blK-l}) are generated using the Trip[] generator as 
described in sub-clause B.5.4.4. The K source triples are associated with the K source symbols and are then used to 
determine theL intermediate symbols C[0],..., C[L-1] from the source symbols using an inverse encoding process. This 
process can be can be realized by a Raptor decoding process. 

Certain "pre -coding relationships" must hold within the L intermediate symbols. Sub-clause B.5. 2 describes these 
relationships and how the intermediate symbols are generated from the source symbols. 

Once the intermediate symbols have been generated, repair symbols are produced and one or more repair symbols are 
placed as a group into a single data packet. Each repair symbol group is associated with an Encoding Symbol ID (ESI) 
and a number, G, of encoding symbols. The ESI is used to generate a triple of three integers, {d, a, b) for each repair 
svmbol, again using the Trip[] generator as described in sub-clause B.5.4.4. This is done as described in sub-clauses B.3 
and B.4 using the generators described in sub-clause B.5.4 . Then, each {d,a,b)-tnple is used to generate the 
corresponding repair symbol from the intermediate symbols using the LTEnc[/r, C[0],..., C[L-1], {d,a,b)] generator 
described in sub-clause B.5. 4. 3. 

B.5. 2 First encoding step: Intermediate symbol Generation 
B. 5.2.1 General 

The first encoding step is a pre-coding step to generate the L intermediate symbols C[0], ..., C[L-1] from the source 
symbols C'[0], ..., C'[/r-l]. The intermediate symbols are uniquely defined by two sets of constraints; 
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1 . The intermediate symbols are related to the source symbols by a set of source symbol triples. The generation of 
the source symbol triples is defined in sub-clause B.5.2.2 using the the Trip[] generator as described in sub- 
clause B.5.4.4. 

2. A set of pre-coding relationships hold within the intermediate symbols themselves. These are defined in sub- 
clause B.5.2.3. 

The generation of the L intermediate symbols is then defined in sub-clause 5.2.4. 

B.5.2.2 Source symbol triples 

Each of the K source symbols is associated with a triple {d{i\, a{i\, b{i\) for 0<i<K. The source symbol triples are 
determined using the Triple generator defined in sub-clause B.5.4.4 as: 

For each i,Q<i<K 

{d[i\, a[i\, b[i\) = Trip[/:, i\ 

B.5.2.3 Pre-coding relationships 

The pre-coding relationships amongst the L intermediate symbols are defined by expressing the last L-K intermediate 
symbols in terms of the first K intermediate symbols. 

The last L-TT intermediate symbols C{K\,...,C{L-\} consist of S LDPC symbols and H Half symbols The values of S and 
H are determined from K as described below. Then L= K+S+H. 

Let 

X be the smallest positive integer such that X-(X-l) >= 2-K. 
S be the smallest prime integer such that S > ceil(0.01 -TT) + X 
H be the smallest integer such that choose(//,ceil('///2j) >K+S 
H' = ceil(///2) 
L = K+S+H 

C[0],..., C[K-1] denote the first /T intermediate symbols 
C[K],..., C[K+S-l] denote the S LDPC symbols, initiahsed to zero 
C[K+S],..., C[L-1] denote the //Half symbols, initialised to zero 
The S LDPC symbols are defined to be the values of C[K],..., C[K+S-1] at the end of the following process: 
Foii = Q,...,K-l do 

a=l + (flooiii/S) % (S-1)) 

b = i%S 

C[K+b] = C[K+b]^C[i] 

b = (b + a)%S 

C[K+b] = C[K+b]^C[i] 

b = (b + a)%S 

C[K+b] = C[K+b]^C[i] 
The H Half symbols are defined as follows: 
Let 
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g[i] = i ^ (floor(;72)) for all positive integers / 

Note: g[i] is the Gray sequence, in which each element differs from the previous one in a single bit 
position 

g[j,k] denote the j* element, j=0, 1, 2, ..., of the subsequence of g[/] whose elements have exactly A: non-zero bits in 
their binary representation 

Then, the Half symbols are defined as the values of C[K+S],..., C[L-1] after the following process: 

For/z = 0,...,//-ldo 

Foij = Q,...,K+S-ldo 

If bit h of g[i,H'] is equal to 1 then C[h+K+S] = C[h+K+S] ^ C[/]. 

B.5.2.4 Intermediate symbols 
B.5.2.4.1 Definition 

Given the /T source symbols C'[0], C'[l],..., C'[/r-l] the L intermediate symbols C[0], C[l],..., C[L-1] are the uniquely 
defined symbol values that satisfy the following conditions: 

1. The /T source symbols C'[0], C'[l],..., C'[/r-l] satisfy the /T constraints 

C'[i] = LTEnc[/:, (C[0],..., C[L-1]), (d[i], a[i], b[i])], for all /, 0<i<K. 

2. The L intermediate symbols C[0], C[l],..., C[L-1] satisfy the pre-coding relationships defined in B.5.2.3. 

B.5.2.4. 2 Example method for calculation of intermediate symbols 

This sub-clause describes a possible method for calculation of the L intermediate symbols C[0], C[l ],..., C[L-1] 
satisfying the constraints in sub-clause B.5.2.4.1 

The generator matrix G for a code which generates A^ output symbols from K input symbols is an NxK matrix over 
GF(2), where each row corresponds to one of the output symbols and each column to one of the input symbols and 
where the /* output symbol is equal to the sum of those input symbols whose column contains a non-zero entry in row i. 

Then, the L intermediate symbols can be calculated as follows: 

Let 

C denote the column vector of the L intermediate symbols, C[0], C[l],. . ., C[L-1]. 

D denote the column vector consisting of S+H zero symbols followed by the K source symbols C'[0], C'[l], . . ., 
C'[K-1] 

Then the above constraints define an LxL matrix over GF(2), A, such that: 

AC = D 
The matrix A can be constructed as follows: 
Let: 

Gldpc be the Sx K generator matrix of the LDPC symbols. So, 
Gldpc-(C[0], ...,C[K-1]Y=(C[K], ...,C[K+S-1]Y 

Gnaif be the H x (K+S) generator matrix of the Half symbols. So, 
Gnaif (C[0], ..., C[S+K-l]f = (C[K+S], ..., C[K+S+H-l]f 

Is be the S xS identity matrix 

I// be the HxH identity matrix 
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OsxH be the S xH zero matrix 

Glt be the KxL generator matrix of the encoding symbols generated by the LT Encoder. 

So, 

Glt- (C[0], ..., C[L-l]f = (C'[0], C'[l],..., C'[K-l] f 

i.e. Guij = 1 if and only if C[j] is included in the symbols which are XORed to produce LTEnc[/r, (C[0], . . ., 
C[L-1]), (d[i], a[i], b[i])]. 

Then: 

The first S rows of A are equal to Gldpc I Is IZsxh. 

The next H rows of A are equal to Gnait 1 1//. 

The remaining K rows of A are equal to Glt- 
The matrix A is depicted in the figure below: 



K 



H 



H 



K 



Gldpc 


I. 


'^SxH 


Gnaif 


Ih 


Glt 



Figure B.5.2.5.2-1 : The matrix A 

The intermediate symbols can then be calculated as: 

c = a'd 

The source triples are generated such that for any K matrix A has full rank and is therefore invertible. This calculation 
can be realized by applying a Raptor decoding process to the K source symbols C'[0], C'[l],. . ., C'[/r-l] to produce the 
L intermediate symbols C[0], C[l ],..., C[L-l]. 

To efficiently generate the intermediate symbols from the source symbols, it is recommended that an efficient decoder 
implementation such as that described in [91] section 5.5 be used. The source symbol triples are designed to facilitate 
efficient decoding of the source symbols using that algorithm. 

B.5.3 Second encoding step: LT encoding 

In the second encoding step, the repair symbol with ESI X is generated by applying the generator LTEnc[/r, (C[0], 
C[l],..., C[L-1]), (d, a, b)] defined in sub-clause B. 5. 4 to the L intermediate symbols C[0], C[l],..., C[L-l] using the 
triple (d, a, b)=Thp[K,X] generated according to sub-clauses B. 3.2.2 and B.4.2. 
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B.5.4 Generators 
B.5.4.1 Random Generator 

The random number generator Rand[X, /, m] is defined as follows, where X is a non-negative integer, / is a non-negative 
integer and m is a positive integer and the value produced is an integer between and m-1. Let Vq and Vi be arrays 
of 256 entries each, where each entry is a 4-byte unsigned integer. These arrays are provided in sub-clause B.7. 

Then, 

RandK /, m] = (Vo[(X + i) % 256] '^ yi[(floor(X/256)H- /) % 256]) % m 

B.5.4. 2 Degree Generator 

The degree generator Deg[v] is defined as follows, where v is an integer that is at least and less than 2^" = 1048576. 
In Table B.5.4.2-1, find the index; such that/ly-l] < v </[/'] 
Deg[v] = d[j] 

Table B.5.4.2-1 - Defines the degree distribution for encoding symbols 
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B.5.4. 3 LT Encoding Symbol Generator 

The encoding symbol generator LTEnc[/r, (C[0], C[l],..., C[L-1]), (d, a, b)] takes the following inputs: 

K is the number of source symbols (or sub-symbols) for the source block (sub-block). Let L be derived from K as 
described in sub-clause B.5.2, and let L' be the smallest prime integer greater than or equal to L. 

(C[0], C[l],..., C[L-1]) is the array of L intermediate symbols (sub-symbols) generated as described in sub-clause 
B.5.2 

(d, a, b) is a source triple determined using the Triple generator defined in sub-clause B.5.3.4, whereby 

d is an integer denoting an encoding symbol degree 

a is an integer between 1 and L'-l inclusive 

b is an integer between and L'-l inclusive 
The encoding symbol generator produces a single encoding symbol as output, according to the following algorithm: 
While (b > L) do b = (b + a) % L' 
Let result = C[b]. 
Fory = l,...,imn(d-l,L-l) do 

b = {b + a)% U 
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While (b > L) do b = (b + a) % U 
result = result '^ C[b] 
Return result 

B.5.4.4 Triple generator 

The triple generator Trip[/r,X] takes the following inputs: 

K The number of source symbols 

X An encoding symbol ID 
Let 

L be determined from K as described in sub-clause B.5.2 

L' be the smallest prime that is greater than or equal to L 

Q = 65521, the largest prime smaller than 2"". 

J(K) be the systematic index associated with K, as defined in sub-clause B.7 
The output of the triple generator is a triples, (d, a, b) determined as follows: 

1. A = (53591 H-7(r)-997)%Q 

2. B= 10267-(J(K)+1)%Q 

3. Y=(B + X-A)%Q 

4. V = Rand[y, 0, 2^"] 

5. d=Beg[v] 

6. fl= 1 H-Rand[F, 1,L'-1] 

7. b = Rand[Y,2,U] 
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B.6 Systematic Indices J(/<)) 

The J(K) indices are defined in [91], clause 5.7 



B.7 Random Numbers 

The two tables Vq and Vi are defined in [91], clause 5.6.1 and 5.6.2 respectively. 



B.8 Void 
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Annex C (informative): 
lANA registration 

This annex provides the required lANA registration. 



C.1 Registration of SDP Protocol Identifiers for Source 
packet 

This specification defines two new SDP protocol identificators for source packets. As the registration rules requires 
these to be registered by an RFC, there will be an RFC referencing the definitions here. 

Protocol identifier "UDP/MBMS-FEC/RTP/AVP" identifies a protocol combination of UDP[7], FEC source packets 
(see sub-clause 8.2.2.4), RTP [6] using the AVP profile [78]. This protocol identifier shall use the FMT space rules that 
are used for RTP/ AVP. 

Protocol identifier "UDP/MBMS-FEC/RTP/SAVP" identifies a protocol combination of UDP [7], FEC source packets 
(see sub-clause 8.2.2.4), and RTP [6] using the SAVP profile [77]. This protocol identifier shall use the FMT space 
rules that are used for RTP/AVP. 



C.2 Registration of SDP Protocol identifier for repair 
packets 

This specification defines one new SDP protocol identificator for FEC repair packets. As the registration rules requires 
these to be registered by an RFC, there will be an RFC referencing the definitions within this specification. 

Protocol identifier "UDP/MBMS-REPAIR" identifies a protocol combination of UDP [7], FEC repair packets (see sub- 
clause 8.2.2.4). The FMT string is not used and shall be set to "*". 



C.3 Registration of MIME type 

"application/simpleSymbolContainer" 

The MIME Type "application/simpleSymbolContainer" denotes that the message body is a simple container of 
encoding symbols for the file repair procedure (clause 9.3.5.2 - File Repair Response Message Format for HTTP 
Carriage of Repair Data). 

Type name: application 

Subtype name: simpleSymbolContainer 

Required parameters: 

None 
Optional parameters: 

None 

Encoding considerations: 

The content is binary and if transported in a protocol not capable of handling binary content then the object must 
be encoded, for example using base64 [82]. 



£75/ 



3GPP TS 26.346 version 9.1 .0 Release 9 1 25 ETSI TS 1 26 346 V9.1 .0 (201 0-01 ) 

Security considerations: 

The content of this media type are either source or repair symbols part of a binary file object. Thus it security 
considerations depends on the security requirements on the file object. As modification of the response message 
may corrupt the complete file object due to the FEC repair operations, integrity protection is recommended. 
Source authentication is also recommended to prevent man in the middle or spoofing attacks resulting in 
erronous repair symbols. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based apphcations 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.4 Registration of IVIIIVIE type "application/mbms-user- 
service-description+xml " 

The MIME Type "application/mbms-user-service-description+xml" denotes that the message body is a user service 
description instance in accordance with the XML schema "urn:3GPP:metadata:2005:MBMS:userServiceDescription" 

(see sub-clause 11.2.1). 

Type name: application 

Subtype name: mbms-user-service-description+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 
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Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

This media format is used to configure the receiver on how to participate in a service. This format is highly 
suspectible to manipulation or spoofing for attacks desring to misslead a receiver about a session. Both integrity 
protection and source authentication is recommended to prevent missleading of the receiver. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based applications 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: None 

Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.5 Registration of IVIIIVIE type 

"application/mbms-envelope+xml " 

The MIME Type "application/mbms-envelope+xml" denotes that the message body is a metadata envelope according to 
the XML schema "urn:3gpp:metadata:2005:MBMS:envelope" (see sub-clause 11.1.3). 

Type name: application 

Subtype name: mbms-envelope+xml 

Required parameters: 

None 

Optional parameters: 
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embedded: Declares if all objects described in this envelope instance are embedded within the this envelope 
instance. The value is either (false) or 1 (true) and when this parameter is omitted the value 
defaults to (false). 

referenced; Declares if all objects described in this envelope instance are referenced, none is embedded within 
the envelope. The value is either (false) or 1 (true) and when this parameter is omitted the value 
defaults to (false). 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

This media format contains information about versioning and validity of files, telling the receiver if it should 
invalidate already received files or replace previously received files with new version contained or referenced 
within this format. Thus modifying or spoofing an envelope is a simple way of making denial of service attack. 
Thus source authentication and integrity protection of the files are recommended. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based applications 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 
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C.6 Registration of IVIIIVIE type 

"application/mbms-protection-description+xml " 

The MIME-Type "application/mbms-protection-description+xml" denotes that the message body is an MBMS 
protection description XML document according to the scheme identified as 
"iirn:3GPP:metadata:2005:MBMS:securityDescription" (see sub-clause 11.3.1). 

Type name: application 

Subtype name: mbms-protection-description+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RPC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The media format is used to configure the security functions of the MBMS delivery. Thus a target for any 
attacker that would like modify a receivers understanding of the security functions, either for a denial of service 
attack or a session replacement attack. However the format contains no seceret information that may not be 
shared openly. All security keys are handled using other mechanisms. Source authentication and integrity 
protection is recommended. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based applications 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

Author: 

3GPP TSG SA WG4 

Change controller: 
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3GPP TSG SA WG4 

C.7 Registration of IVIIIVIE type 

"application/mbms-associated-procedure- 
description+xml" 

The MIME-Type "application/mbms-associated-procedure-description+xml" denotes that the message body contains 
the associated procedure description in XML following the schema 
"urn:3gpp:metadata:2005:MBMS:associatedProcedure" (see sub-clause 9.5.1). 

Type name: application 

Subtype name: mbms-associated-procedure-description+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The information present in this media format is used to configure the receiving application. Thus the usage of the 
fomat is vulnerable to attacks modifying or spoofing the content of this format. It is recommended to use source 
authentication and integrity protection. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based apphcations 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

Author: 
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3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



130 



ETSI TS 126 346 V9.1.0 (2010-01) 



C.8 Registration of IVIIIVIE type "application/mbms- 
msk+xml" 

The MIME-Type "application/ mbms-msk+xml" denotes that the message body contains the MSK request parameters 
in accordance with the XML scheme "urn:3GPP:metadata:2005:MBMS:mskRequest" (see sub-clause 11.6 and 3GPP 
TS 33.246 [20]). 

Type name: application 

Subtype name: application/mbms-msk+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The usage of the format is to identify one or more MSK that the requesting entity desires to receive. 
Modification or changes to this format thus only result in a denial of service attack. Integrity protection would 
protect against such modifications. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based apphcations 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 
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None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 
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C.9 Registration of IVIIIVIE type "application/mbms- 
register+xml" 

The MIME-Type "application/mbms-register+xml" denotes that the message body contains the MBMS User Service 
Registration parameters in accordance with the XML schema "urn:3GPP:metadata:2005:MBMS:securityRegistration" 
(see sub-clause 11.4 and 3GPPTS 33.246 [20]). 

Type name: application 

Subtype name: mbms-register+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The content of this format identifies a user service that the document creator desires to register to. Any 
modificatons of this document would allow an attacker to change to what services the creator registers to. To 
prevent this integrity protection is necessary. There is also necessary to authenticate the entity performing the 
registration to know who is the one performing the registration request. In MBMS this is accomplished using 
procedures described in 3GPP TS 33.246. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based appUcations 
Additional information: 
Magic number(s): None 
File extension(s): 
Macintosh file type code(s): 
Person & email address to contact for further information: 
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Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.10 Registration of IVIIIVIE type "application/mbms- 
deregister+xml" 

The MIME-Type "application/mbms-deregister+xml" denotes that the message body contains the MBMS User Service 
Deregistration parameters in accordance with the XML schema 

"urn:3GPP:metadata:2005:MBMS:securityDeregistration" (see sub-clause 11.5 of 3GPPTS 26.346 and 3GPP 
TS 33.246 [20]). 

Type name: application 

Subtype name: mbms-deregister+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The content of this format identifies a user service that the document creator desires to register to. Any 
modificatons of this document would allow an attacker to change to what services the creator registers to. To 
prevent this integrity protection is necessary. There is also necessary to authenticate the entity performing the 
registration to know who is the one performing the registration request. In MBMS this is accomplished using 
procedures described in 3GPP TS 33.246. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based apphcations 
Additional information: 
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Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.1 1 Registration of IVIIIVIE type "application/mbms- 
reception-report+xml" 

The MIME-type registration for "application/mbms-reception-report+xml" that identifies XML documents that 
follows the schema "urn:3gpp:metadata:2005:MBMS:receptionreport" defined in clause 9.5.3. 

Type name: application 

Subtype name: mbms-reception-report+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The reception report XML document instances contain information about what services and files that a particular 
receiver has received. Thus to prevent manipulation of that information it would need to be integrity protected. 
The information also has privacy relevance as it reveals what a specific receiver, which usually can be connected 
to a specific user, has received. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 
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3GPP MBMS based applications 
Additional information: 

None 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.12 Registration of IVIIIVIE type "application/mbms-msk- 
response+xml" 

The MIME Media Type "application/ mbms-msk-response+xml" denotes that the message body contains the response 
codes to MSK request procedure in accordance with the XML scheme 
"urn:3GPP:metadata:2005:MBMS:mskResponse" (see sub-clause 11.8 and 3GPP TS 33.246 [20]). 

Type name: application 

Subtype name: mbms-msk-response+xml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The usage of the format is to identify one or more response codes of MSK requests procedures. Modification or 
changes to this format thus only result in a denial of service attack. Integrity protection would protect against 
such modifications. In MBMS this is accomplished using procedures described in 3GPP TS 33.246. 

Interoperability considerations: 

None 
Published specification: 

3GPP TS 26.346 
Applications which use this media type: 
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3GPP MBMS based applications 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 



C.13 Registration of IVIIIVIE type "application/mbms- 
register-response+xml" 

The MIME Media Type "application/mbms-register-response+xml" denotes that the message body contains the 
response codes to an MBMS User Service Registration or MBMS User Service De-Register procedure in accordance 
with the XML schema "urn:3GPP:metadata:2005:MBMS:securityRegistrationResponse" (see sub-clause 11.7 and 
3GPPTS 33.246 [20]). 

Type name: application 

Subtype name: mbms-register-response-Hxml 

Required parameters: 

None 
Optional parameters: 

charset: As specified in RFC 3023 [83] for media type application/xml. 

Encoding considerations: 

This is an XML document and the encoding considerations are the same as for media type "application/xml" 
defined in RFC 3023 [83]. 

Security considerations: 

The usage of the format is to identify one or more response codes of registration or deregistration procedures. 
Modification or changes to this format thus only result in a denial of service attack. Integrity protection would 
protect against such modifications. In MBMS this is accomplished using procedures described in 3GPP TS 

33.246 

Interoperability considerations: 
None 
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Published specification: 

3GPP TS 26.346 
Applications which use this media type: 

3GPP MBMS based apphcations 

Additional information: 

Magic number(s): None 

File extension(s): 

Macintosh file type code(s): 

Person & email address to contact for further information: 

Magnus Westerlund (magnus.westerlund@ericsson.com) 
3GPP TSG SA WG4 

Intended usage: COMMON 

Restrictions on usage: 

None 
Author: 

3GPP TSG SA WG4 
Change controller: 

3GPP TSG SA WG4 
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Annex D (informative): 

RTP packetization guidelines 



This annex provides guidelines for MBMS senders to minimize initial buffering delay between starting of the reception 
and starting of rendering of media data in MBMS receivers. 

When H.264 (AVC) video is in use, an MBMS sender should form FEC source blocks in which the first H.264 (AVC) 
access unit in decoding order is an IDR access unit. 

MBMS senders should transmit all application data units for a given H.264 (AVC) access unit, or audio frame within 
one FEC source block. 

MBMS senders should set the min-buffer-time MIME/SDP parameter and the minimum buffering delay elements 
included in FEC source blocks to values that are sufficient to cover any required de -interleaving of application data 
units, such as H.264 (AVC) NAL units and coded audio frames, from their transmission order to decoding order. 

When RTP timestamps are converted to the wallclock time of the MBMS receiver, the smallest RTP timestamp among 
the FEC source packets of a FEC source block of a stream should be equal or close to the smallest RTP timestamp 
among the FEC source packets of a FEC source block of any other stream of the same MBMS streaming session. 

When RTP timestamps are converted to the wallclock time of the MBMS receiver, the greatest RTP timestamp among 
the FEC source packets of a FEC source block of a stream should be equal or close to the greatest RTP timestamp 
among the FEC source packets of a FEC source block of any other stream of the same MBMS streaming session. 

When DIMS content is used, suitable media level recovery (a random access point such as a replacement scene, 
redundant scene, etc.) should be present at the beginning of each FEC source block. This facilitates immediate 
rendering of the DIMS content after FEC decoding, thus reducing tune -in latency. 
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Annex E (informative): 
Void 
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Annex F (informative): 
Hybrid Streaming Delivery 

F.1 Introduction 

In hybrid streaming delivery scenarios it is assumed that a set of streaming services is available over MBMS and a set 
of streaming services is available over PSS. MBMS services may not be available in some service areas, in which cases 
those services might be alternatively provided via PSS. 

Different switching cases between PSS and MBMS and vice versa may occur in these scenarios, including user-initiated 
content switching with access change as well as application-initiated access change. The latter can occur when a service 
is available over MBMS in some service areas but not available over MBMS in other service areas, assuming that the 
service is provided over PSS as a fall-back. 

This annex describes some methods to improve switching times in such hybrid streaming delivery scenarios. 



F.2 Switching between IVIBIVIS and PSS Access 



F.2.1 Synchronization of Flows 



For switching between MBMS and PSS access while receiving the same service, comparing the SSRC values of the 
PSS and MBMS flows gives the UE an advantage for synchronization onto the flows as described in sub-clause 8.5. 

In order to allow for an as interruption-free access switch as possible, the time offset between MBMS packet reception 
and PSS packet reception (including MBMS FEC buffering and PSS retransmission delays) should be as small as 
possible. 

It is advantageous (but not always possible) that the same set of codecs is used for representing the same service over 
both accesses. If the same media bit rates are provided over both accesses, then at best the same media flows (identical 
media encoding) are used for both accesses. This gives the UE an advantage of being able to continuously using 
decoding buffers thus simplifying seamless access switching. In case the codecs or codec level/profiles change upon 
access switching, the UE needs to prepare a new set of decoders and possibly having them run in parallel for a short 
period of time. 

F.2.2 Switching from MBMS to PSS Access 

Switching from MBMS to PSS can happen in two cases, user-initiated content switch with access change and 
application-initiated access change. 

• User-initiated content switch with access change: The user requests reception of a service other than the 
one currently received over MBMS, and the new service is only available over PSS. 

• Application-initiated switch of access; The MBMS coverage is lost and alternative reception of the same 
service is possible over PSS. 

The latter case may occur suddenly and without warning when the available signal strength is no longer good enough 
for the MBMS reception. The UE may identify the loss of MBMS access by signal strength measurements, detection of 
packet losses exceeding a certain threshold, or that RTP reception has stopped completely. As a result the UE may 
terminate the MBMS session and initiate service reception over PSS instead. 

In case MBMS coverage is lost and the corresponding PSS session is requested, the UE may use PSS time-shifting (as 
defined in TS 26.234 [47]) for signalling a PSS play-out start corresponding to the time instant the MBMS access was 
lost, giving the advantage of synchronization of the received flows. 
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F.2.3 Switching from PSS to IVIBIVIS Access 

Switching from PSS to MBMS can happen in two cases, user-initiated content switch with access change and 
application-initiated access change. 

• User-initiated content switch with access change: The user requests reception of a service other than the 
one currently received over PSS, and the new service is available over MBMS. 

• Application-initiated switch of access: The UE recognizes that MBMS reception of that service is 
alternatively possible (e.g. because MBMS reception was re-gained), such that the UE may terminate the 
PSS session and initiate reception over MBMS. 

If the UE can receive both PSS and MBMS flows at the same time, and the time offset between MBMS packet 
reception and PSS packet reception (including MBMS EEC buffering and PSS retransmission delays) is small, and 
identical media encoding is used, then application-initated access change from PSS to MBMS without service change is 
possible to be made in such a way that it is seamless. 
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Annex G (informative): 

Guidelines for Channel Tune-in and Switch Time Reduction 

This Annex describes some methods to improve channel tune-in and switching times for MBMS Streaming when using 
the FEC framework. It presents means for MBMS senders and receivers to minimize delay from a channel switch and 
initial tune-in time. Fast startup improvements for the layers below IP are not described here. 



G.1 Interleaving for Tune-in Time Reduction of FEC 
protected MBMS Services 

Interleaving may be applied to source blocks before FEC encoding to re-arrange the order of transmission of the UDP 
packets. The target of the interleaving is to provide high priority and correctly decodeable media units in a way that 
maximizes the resulting media duration at the receivers that tune in at that specific source block. The interleaver may 
operate at two different levels: 

• Inter-stream interleaving: prioritize the media streams and arrange their transmission order according to the 
ascending order of priorities. In other words high priority data, e.g. audio data, is transmitted towards the end 
of the source block. 

• Intra-stream interleaving: high priority media data units such as Random Access Points of a video stream are 
transmitted towards the end of a source block. 

The interleaving procedure enables receivers to reliably decode and present media data that has been received from a 
fraction of the tune-in source block. 

Interleaving is transparent to legacy receivers. 



G.1 .1 Timestamp Offsets 



The timestamp offset field may be used to signal a timestamp offset for the received media units in the FEC block as 
specified in 8.2.3.2. 

The timestamp offsets may be used to reconstruct the presentation time line at the UE. They may also be used to reduce 
the out time caused by the reception of a partially received interleaved FEC source block as shown in figure G.1. 
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Figure G.1 : Early tune-in using variable timestamps 
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G.1.2 Early Playout 



A UE that desires to make use of the interleaving to reduce the tune-in time may start the playout earher than dictated 
by the min-buffer-time value. 

Instead, the UE may schedule the first media unit of the succeeding source block to be played out after the min-buffer- 
time. It may then estimate the appropriate time for starting early playout based on the amount of media duration that 
was received from the current block, the playout time of the earliest media unit of the next source block, and the highest 
presentation time of the media units of the current source block. 

The early playout behavior is depicted by the following figure. 
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Figure G.2: Early play out of interleaved media data of a FEC protected MBMS service 



G.2 FEC Stream & Channel Bundling 
G.2.1 Introduction 

FEC Stream bundling is a method of improving the FEC efficiency and also to improve channel switching times. 
Several flows of one or more user services are "bundled" to form the source blocks for the FEC calculations. . This 
means, that all flows must be received for potential FEC recovery. 

If flows from more than one user service are bundled (i.e. Channel Bundling), then the receiver discards other services 
after FEC processing. When a switch is performed, media inside the same bundle is immediately available. Stream 
Bundling can be performed on whole channels, parts of channels, or not at all. 

Note; FEC Bundling does not improve start-up times. 

G.2.1 .1 Full Channel Bundling (All flows of several user services) 

When full bundling is used, more than one complete channel is bundled. A channel switch inside the bundle does not 
require rebuffering and can therefore be near instantaneous. However, full bundling requires the processing of all 
packets. In other words, at a single time instance all video streams and all audio streams are received and processed. 
Also, the number of channels possible is limited by the fixed bearer bandwidth. 
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G.2.1.2 No Bundling 

When no bundling is used, each channel is protected separately. In a channel switch the new channel needs to be 
buffered for the full min-buffer-time. At a single time instant one video stream and one audio stream is received and 
processed. 

G.2.1 .3 Partial Channel Bundling (Some flows of several user services) 

Partial bundling may be used to combine some of the benefits of full bundling and no bundling. In this case more than 
one parital channel is bundled. This may be used to reduce the processing required on the terminal while retaining fast 
channel switching between parts of the media. 

Partial bundling may be used to bundle only the audio part of channels. In other words, at a single time instance one 
video stream and all audio streams are received. When a switch occurs the audio is switched instantaneously as it does 
not need to be rebuffered. The complexity of this case is substantially lower than full bundling and the number of 
channels which can be bundled given a fixed bearer bandwidth is substantially increased. This is due to the fact that 
the audio uses a substantially lower percentage of the bitrate compared to video. 

G.2.1 .3 Stream Bundling (All flows of a single user services) 

When stream bundling is used, all flows of a single channel are bundled. The FEC source block is formed using audio, 
video and security data. 
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Annex H (informative): 

QoE Reporting IVIanagement Object Device Description 

Framework 

This Device Description Framework (DDF) is the standardized minimal set. A vendor can define its own DDF for the 
complete device. This DDF can include more features than this minimal standardized version. 

<?xml version="l . 0" encoding="UTF-8" ?> 

<!DOCTYPE MgmtTree PUBLIC " -//OMA//DTD-DM-DDF 1.2//EN" 

"http : //www . openmobilealliance . org/tech/DTD/dm_ddf -vl_2 . dtd" > 

<MgmtTree> 

<VerDTD>l . 2</VerDTD> 

<Man>--The device manufacturer- -</Man> 

<Mod>--The device model- -</Mod> 

<Node> 

<NodeName>3GPP_MBMSQ0E</NodeName> 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<Scope> 

<Permanent/> 
</Scope> 

<DFTitle>The interior node holding all 3GPP MEMS QoE Metrics Reporting objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
<Node> 

<NodeName >Enabled< /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<bool/> 
</DFFormat> 
<Occurrence> 

<One/> 
< /Occurrence > 
<Scope> 

< Permanent /> 
</Scope> 

<DFTitle>The QoE reporting requested indicator</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >APN< /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The Access Point Name for QoE reporting</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
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</Node> 
<Node> 

<NodeName >Format < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The QoE metrics report f ormat</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >Rules < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<One/> 
< /Occurrence > 

<DFTitle>The QoE metrics rules</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName>Session< /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The QoE session metrics node</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
<Node> 

<NodeName>Metrics</NodeName> 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >Ext < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
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<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 

< /Occurrence > 
<Scope> 

< Permanent /> 
</Scope> 

<DFTitle> A collection of all extension objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
</Node> 
<Node> 

<NodeName>Speech</NodeName> 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The QoE speech metrics node</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
<Node> 

<NodeName>Metrics</NodeName> 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >Ext < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<Scope> 

< Permanent /> 
</Scope> 

<DFTitle> A collection of all extension objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
</Node> 
<Node> 

<NodeName >Video< /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
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<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The QoE video metrics node</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
<Node> 

<NodeName>Metric</NodeName> 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrMore/> 
< /Occurrence > 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >Ext < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<Scope> 

< Permanent /> 
</Scope> 

<DFTitle>A collection of all extension objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
</Node> 
<Node> 

<NodeName >Text < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 

<DFTitle>The QoE timed text metrics node</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
<Node> 

<NodeName >Me t r i c < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 

<chr/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
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<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
<Node> 

<NodeName >Ext < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<Scope> 

< Permanent /> 
</Scope> 

<DFTitle>A collection of all extension objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
</Node> 
<Node> 

<NodeName >Ext < /NodeName > 
<DFProperties> 
<AccessType> 

<Get/> 
</AccessType> 
<DFFormat> 
<node/> 
</DFFormat> 
<Occurrence> 

<ZeroOrOne/> 
< /Occurrence > 
<Scope> 

<Permanent/> 
</Scope> 

<DFTitle>A collection of all extension objects</DFTitle> 
<DFType> 

<DDFName/> 
</DFType> 
</DFProperties> 
</Node> 
</Node> 
</MgmtTree> 
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